Payment Ledger
ERPNext introduced the Payment Ledger in version 14 to separate payment-specific activity from the General Ledger. Prior to version 14, the GL carried full responsibility for accounting impacts, linking payments, and calculating outstanding balances on invoices. Frappe developers noted in the version 14 migration guide that maintaining payment link information in the GL was a "bottleneck for the immutability of the GL Entries" 1. By separating the two ledgers, ERPNext improved performance in report generation, payment reconciliation, and outstanding balance calculations, and made the immutable ledger feature viable.
The Payment Ledger (PL) records the amount of each payment allocation, the party and account it is tied to, and a link to the source voucher. It is the authoritative source for calculating outstanding balances on invoices and for the Accounts Payable and Accounts Receivable reports. The General Ledger remains the source of truth for all accounting entries; the two ledgers serve different purposes and must be read together to get a complete picture of a transaction. Unlike the GL, the Payment Ledger does not use double-entry debits and credits. Each Payment Ledger Entry (PLE) carries a single signed amount: positive for an obligation created (an invoice posted) and negative for an obligation satisfied (a payment applied). The net sum of all linked PLEs against a voucher is its outstanding balance.
Immutable Ledger
ERPNext applies the immutable ledger principle to the Payment Ledger: cancelling a payment does not delete the original PLE, but adds one or more new PLEs that offset it. The behavior of those offsetting entries depends on whether the immutable ledger feature is enabled in Accounts Settings. This feature is not enabled by default as of version 15.
When the immutable ledger feature is not enabled, cancellation creates an offsetting PLE dated to the original payment's posting date, then delinks both entries. Delinked PLEs are excluded from all report data, so the invoice appears outstanding for any report date, as if the payment never occurred.
When the immutable ledger feature is enabled, cancellation creates an offsetting PLE dated to the cancellation date, and both entries remain linked. Linked PLEs are included in report data, so the invoice appears paid for any report date before the cancellation date and outstanding for any report date on or after it.
Submitting a Purchase Invoice
Chelsea Fruit Company creates a Purchase Invoice to Supplier ABC for $5,000 with Net 30 terms. Posting date is Nov-01 and due date is Dec-01. Submitting the invoice creates one GL entry and one PLE. The PLE records the obligation as a positive amount against the invoice voucher.
General Ledger
| Date | Account | Party | Debit | Credit |
|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | $5,000.00 | |
| Nov-01 | Inventory Received But Not Billed | $5,000.00 |
Payment Ledger
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
The Accounts Payable Report draws its data from the Payment Ledger. On Nov-01 the invoice shows as outstanding with an Age of -30 days — ERPNext calculates aging as the difference between the report date and the due date, so an invoice not yet due carries a negative age.
| Posting Date | Party | Voucher Type | Due Date | O/S Amt | Age (Days) |
|---|---|---|---|---|---|
| Nov-01 | Supplier ABC | Purchase Invoice | Dec-01 | $5,000.00 | -30 |
Submitting a Payment Entry
On Dec-01 the company creates a Payment Entry to pay the invoice in full. Submitting the Payment Entry creates GL entries that debit Accounts Payable and credit the bank account, and adds a negative PLE against the same voucher. The net of the two PLEs is zero, so the invoice no longer appears in the Accounts Payable Report for any report date on or after Dec-01.
General Ledger
| Posting Date | Account | Party | Debit | Credit |
|---|---|---|---|---|
| Dec-01 | Accounts Payable | Supplier ABC | $5,000.00 | |
| Dec-01 | Primary Checking | $5,000.00 |
Payment Ledger
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | -$5,000.00 | Yes |
Cancelling a Payment Entry
Let's continue this narrative example: the check was printed with an incorrect check number. The user cancels and amends the Payment Entry in ERPNext, corrects the reference number to match the paper check and submits. The GL and Payment Ledger behavior depends on whether the immutable ledger feature is enabled.
Immutable ledger not enabled (default): the GL reversal is dated to the original payment date. An offsetting PLE is added using the same posting date, and both the original and offsetting payment PLEs are delinked. Delinked PLEs are excluded from all report data, so the invoice reappears as outstanding for any report date, including dates between Dec-01 and the cancellation date, as if the payment never occurred.
| Posting Date | Account | Party | Debit | Credit |
|---|---|---|---|---|
| Dec-01 | Accounts Payable | Supplier ABC | $5,000.00 | |
| Dec-01 | Primary Checking | $5,000.00 |
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | -$5,000.00 | No |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | No |
Immutable ledger enabled: the GL reversal is dated to the cancellation date. An offsetting PLE is added using the cancellation date, and all PLEs remain linked. The invoice appears paid for any report date between Dec-01 and the day before cancellation, and outstanding again from the cancellation date onward.
| Posting Date | Account | Party | Debit | Credit |
|---|---|---|---|---|
| Dec-31 | Accounts Payable | Supplier ABC | $5,000.00 | |
| Dec-31 | Primary Checking | $5,000.00 |
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | -$5,000.00 | Yes |
| Dec-31 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
Cancelling an Invoice with a Payment Already Applied
The company discovers a line item error on ACC-PINV-0001 after ACC-PAY-0001 has already been submitted against it. In v15, with "Unlink Payment on Cancellation of Invoice" enabled in Accounts Settings (the default), cancelling the invoice does not require cancelling the Payment Entry first. ERPNext automatically calls the same unlink mechanism used by the Unreconcile Payment tool before reversing the invoice's GL entries.
The GL reversal is dated to the original invoice posting date (Nov-01). The payment PLE's against_voucher reference is updated to point back to itself, releasing the link to the invoice. The invoice PLE is delinked.
General Ledger
| Posting Date | Account | Party | Debit | Credit |
|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | $5,000.00 | |
| Nov-01 | Inventory Received But Not Billed | $5,000.00 |
Payment Ledger after invoice cancellation
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | No |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PAY-0001 | Dec-01 | -$5,000.00 | Yes |
ACC-PINV-0001 no longer appears in the Accounts Payable Report. ACC-PAY-0001 sits unallocated. The Amend action on ACC-PINV-0001 creates ACC-PINV-0001-1 as a new draft. After correcting the line items and submitting, ACC-PINV-0001-1 generates a fresh invoice PLE. The Payment Reconciliation tool is then used to allocate ACC-PAY-0001 against ACC-PINV-0001-1.
Payment Ledger after reallocation to ACC-PINV-0001-1
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001-1 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001-1 | Dec-01 | -$5,000.00 | Yes |
Misallocated Payment: Unreconcile and Reallocate
A $5,000 payment (ACC-PAY-0001) was applied against ACC-PINV-0001 but was intended for ACC-PINV-0002. Both invoices are from Supplier ABC for $5,000. Rather than cancelling the Payment Entry entirely, the company uses the Unreconcile Payment tool to remove the specific allocation.
Before unreconciliation — Payment Ledger state:
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | -$5,000.00 | Yes |
Unlike cancellation, unreconciliation does not create new offsetting PLEs. Instead, ERPNext updates the existing payment PLE's against_voucher reference to point back to the payment voucher itself, releasing the link to ACC-PINV-0001 without adding ledger history.
After unreconciliation — Payment Ledger state:
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0001 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PAY-0001 | Dec-01 | -$5,000.00 | Yes |
ACC-PINV-0001 now shows its full $5,000.00 as outstanding in the Accounts Payable Report. The payment sits unallocated. The Payment Reconciliation tool is then used to allocate ACC-PAY-0001 to ACC-PINV-0002, which creates a new negative PLE linked against that invoice.
After reallocation to ACC-PINV-0002 — Payment Ledger state:
| Posting Date | Account | Party | Voucher | Due Date | Amount | Is Linked |
|---|---|---|---|---|---|---|
| Nov-01 | Accounts Payable | Supplier ABC | ACC-PINV-0002 | Dec-01 | $5,000.00 | Yes |
| Dec-01 | Accounts Payable | Supplier ABC | ACC-PINV-0002 | Dec-01 | -$5,000.00 | Yes |
The GL entries are unchanged throughout — unreconciliation and reallocation touch only the Payment Ledger. ACC-PINV-0001 remains outstanding and ACC-PINV-0002 is now paid. The practical consequence is that unreconciliation leaves no audit trail in the Payment Ledger; only the final state of the PLEs is visible, not the intermediate misallocation. For organizations where auditability of the allocation history matters, cancelling and reissuing the Payment Entry is the more traceable path.
Advance Payments
When a Payment Entry is created against a Sales Order or Purchase Order rather than an invoice, ERPNext records it in a separate Advance Payment Ledger Entry table rather than in the main Payment Ledger Entry table. However, advance PLEs are aggregated with regular PLEs in all outstanding balance calculations and report queries, so they appear seamlessly in the Accounts Payable and Accounts Receivable reports. When the invoice is eventually created and the advance is applied to it, the advance PLE is delinked from the order and a standard PLE link is established against the invoice.