Customer Ledger Entries

"Read-only customer ledger, Business Central's receivables subledger. One row per posted customer 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 customer 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 Net-30 invoice drops out of them while unpaid.

GET custLedgerEntries?$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 AR 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. detailedCustLedgerEntries 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. customerPostingGroup names the control account through customerPostingGroups, 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.