Vendor Ledger Entries

"Read-only vendor ledger, Business Central's payables subledger. One row per posted vendor document, with the remaining amount Business Central itself maintains as payments are applied."

Use this for aging

remainingAmount and open are maintained by Business Central when a payment is applied, and entries here are never purged. That makes an aging built on this feed exact, and it keeps being exact.

The posted vendor feeds are not a substitute. They project onto a short-lived staging table that Business Central purges by posting date after 7, 14 or 28 days, whether or not the document is still open, so a supplier invoice on normal terms drops out of them while unpaid.

GET vendorLedgerEntries?$filter=open eq true and dueDate lt 2026-09-01

Amounts come in both currencies

amount and remainingAmount are in the transaction currency; amountLcy and remainingAmountLcy are the same figures in the company local currency. A multi-currency AP total needs no rate lookup at all, which is the single most common reason a warehouse aging disagrees with Business Central.

Both are FlowFields over the detailed entries, so Business Central computes them as the page reads each row. That is worth knowing when sizing a first load.

Watermark on lastModifiedDateTime

An entry is modified after it is written: settling it updates open, remainingAmount and closedByEntryNumber. A cursor on entryNumber would read each invoice once, while it was still open, and never see it settle.

Where the applications are

This feed says how much is left. detailedVendorLedgerEntries says which payment settled which invoice, when, and for how much. Use that one for a cash-application audit trail or a days-to-pay calculation.

Reaching the G/L

transactionNumber groups every entry written by one posting across ledgers, so it joins this subledger to generalLedgerEntries. vendorPostingGroup names the control account through vendorPostingGroups, which is what a subledger-to-G/L tie-out needs.

Volume

This is a real subledger and can reach millions of rows. Filter a first load by postingDate, then run incrementally.