Detailed Customer Ledger Entries

"Read-only movement detail behind the customer ledger. Every change to an entry's balance gets a row: the initial posting, each application against it, payment discounts, exchange-rate adjustments and unapplications."

The application pair

Two columns carry the audit trail:

• custLedgerEntryNumber is the entry this movement belongs to
• appliedCustLedgerEntryNumber is the entry on the other side of the application

Together they say which payment settled which invoice. That is the only place a partial or split settlement can be seen at all, because the parent feed collapses it into a single remaining amount.

applicationNumber groups the rows written by one application, so a payment spread across five invoices reads as one event rather than five.

Days to pay

postingDate on an application row is the date the settlement happened. Subtracting the invoice's own posting date gives a real days-to-pay per invoice, which is what an average collection period should be built from.

It is genuinely append-only

Unapplying does not edit the original row. Business Central writes a new reversing row and sets unapplied on the old one, so a cursor on entryNumber is safe here even though it is not on the parent feed. Filter out unapplied eq true when totalling, or you will count a reversed settlement twice.

Exchange-rate adjustments move LCY only

An adjustment row carries an amountLcy with amount at zero. That is not bad data: the transaction-currency balance did not change, only its local-currency value did. Totalling amount on this feed and expecting the local-currency movement is the usual way that gets missed.

Volume

Larger than custLedgerEntries, since one entry produces several rows. Filter a first load by postingDate.