> ## Documentation Index > Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt > Use this file to discover all available pages before exploring further. # Payment Reconciliation > Payment reconciliation is the bulk way to match unallocated customer payments to the invoices they should settle. Payment reconciliation is the bulk way to **match unallocated customer payments to the invoices they should settle**. Where the [Payments](/accounting/user/transactions/payments) screen lets you allocate one payment at a time, payment reconciliation looks at *all* the receipts that still have money sitting on account and lines them up against *all* the customer's outstanding invoices — then applies the matches in one go. > **Note on where this lives:** Payment reconciliation is the engine behind matching receipts to invoices. It is exposed through the API (`/api/accounting/payment-reconciliation`) and is driven from the payment-allocation flows on the [Payments](/accounting/user/transactions/payments) page rather than as a separate top-level menu item. The behaviour below is what happens when you auto-match or apply matches. > 📷 *Screenshot: The reconciliation view showing unreconciled payments on the left and outstanding invoices on the right — to be added.* *** ## What it works on Payment reconciliation is **receipt-and-invoice only** — it matches money you've **received** (Money In) against **sales invoices**. Vendor payments and bills are handled through ordinary allocation on the [Payments](/accounting/user/transactions/payments) page. Two lists drive it: ### Unreconciled payments Posted receipts that still have an **unallocated balance** greater than zero — i.e. money you received but haven't yet tied to specific invoices. Each row shows: * Payment number and date * The customer (contact) * The total amount and the **unallocated** amount still available to match * The payment reference You can optionally filter to a single customer. ### Outstanding invoices Sales invoices that still have a **balance due** greater than zero and are in a payable state — **Sent**, **Partially Paid**, or **Overdue**. Each row shows the invoice number, customer, issue date, due date, total, and the balance still owed. The list is ordered by **due date** (oldest first). *** ## Auto-matching The **Auto-match** action proposes matches without changing anything yet. It walks each unreconciled payment and applies its available balance to that **same customer's** outstanding invoices, oldest due-date first (FIFO), until either the payment's balance runs out or the invoices are covered. For each proposed pairing it computes the amount to apply as the **smaller of**: the payment's remaining balance, or the invoice's remaining outstanding. The result is a set of proposed matches plus a count and a total — purely a suggestion you can review. **Important:** auto-match only ever pairs a payment with invoices belonging to the **same customer**. It never moves one customer's money onto another customer's invoice. > 📷 *Screenshot: Auto-match results listing proposed payment → invoice pairings with amounts — to be added.* *** ## Applying matches (Reconcile) The **Reconcile** action takes a set of matches — either the auto-match suggestions or ones you picked by hand — and applies them. Under the hood, each payment's new matches are **merged with its existing allocations** (a match to an invoice the payment already partly covers adds to that allocation rather than duplicating it), and the payment is then re-allocated through the standard payment allocation path. Because it routes through normal allocation, **all the usual guardrails apply**: * The payment's allocations + deductions still can't exceed the payment amount. * No invoice can be allocated more than its outstanding balance. * For an already-posted receipt, applying matches posts a balancing **payment-reconciliation journal entry** so the General Ledger stays in step, and updates each invoice's paid amount, balance due, and status (Partially Paid / Paid). The action returns how many matches were applied and the total amount allocated. ### Behind the scenes Applying a match doesn't create new money movement — the cash already landed when the receipt was posted. What it does is move the receipt's **unallocated balance** onto specific invoices: * Each matched invoice's **balance due** goes down and its **amount paid** goes up; its status is recalculated. * For a posted receipt, a reconciliation journal entry keeps the Accounts Receivable sub-ledger and the GL aligned with the new allocation split. *** ## Tips * Run **Auto-match** first to get a clean FIFO proposal, then adjust individual amounts before you **Reconcile** if a customer wants a payment applied to a specific invoice out of order. * If a receipt still shows an unallocated balance after reconciliation, that money is genuinely "on account" — you can leave it for a future invoice or convert it into a **customer deposit / advance** from the [Payments](/accounting/user/transactions/payments) page. *** ## Related * [Payments & Receipts](/accounting/user/transactions/payments) — record receipts and allocate them one at a time; convert leftover balances into advances. * [Bank reconciliation](/accounting/user/transactions/bank-reconciliation) — a different reconciliation: matching the **bank statement** to the ledger. * [Debts (money lent / other receivables)](/accounting/user/transactions/debts) — non-sale receivables, also cleared through receipts.