Reconcile and Allocate Payments
Use this guide when you have a customer or supplier payment already recorded in NexWave that needs to be applied to one or more invoices. The Payment Reconciliation tool is how you match received customer payments to Sales Invoices, supplier prepayments to Purchase Invoices, and standalone credit or debit notes to their related invoices. The same form works for both Accounts Receivable (AR) and Accounts Payable (AP); only the Party Type changes.
Payment Reconciliation is not the Bank Reconciliation Tool. Use Payment Reconciliation when a Payment Entry (or Journal Entry) already exists in NexWave and needs to be matched to one or more invoices. Use the Bank Reconciliation Tool when you have a line on a bank statement and need to create or find the corresponding Payment Entry. Most months the workflow is: import the bank statement, reconcile bank lines to create Payment Entries, then use Payment Reconciliation for any payments that were not auto-allocated at receipt.
GST is recognised at invoice issuance for invoice-basis filers, so allocating a payment to an invoice has no GST impact for them. If you file GST on a cash basis, see the note in Tips and gotchas, allocation timing matters for the period your GST is recognised in.
Before you start
You will need:
Permission as an Accounts User, Accounts Manager or System Manager.
A Default Receivable Account and Default Payable Account set on the Company. If a customer or supplier uses a non-default account, set the override in the Accounts table on their record.
If your Company has Book Advance Payments in Separate Party Account enabled in Accounts Settings, also set a Default Advance Receivable Account and Default Advance Payable Account on the Company. Advances are stored in the advance account, not the receivable account, and the tool needs to know where to look.
For multi-currency allocations: an Exchange Gain / Loss Account set on the Company, and a sensible Posting Date Inheritance for Exchange Gain / Loss value in Accounts Settings (most period-end allocations want Reconciliation Date).
At least one submitted Payment Entry, Journal Entry posted to the receivable / payable account, or standalone credit / debit note that is not yet applied to an invoice.
Spotting unallocated balances
You usually arrive at Payment Reconciliation because you already know there is an unmatched payment, a customer is asking why their statement still shows an invoice as unpaid, or you have just finished a bulk bank reconciliation. Three ways to surface unallocated balances:
Payment Entry list view. Go to Accounts > Payments > Payment Entry, add a filter for Unallocated Amount > 0, and optionally Payment Type = Receive (for customer payments) or Payment Type = Pay (for supplier payments). This is the simplest flat list across all parties.
Accounts Receivable or Accounts Payable report. Run the report for the date range you care about. Unallocated payments and credit notes show up as negative rows alongside the outstanding invoices for each party, so you can see in one place what is owed and what is sitting against the party unmatched.
Inside Payment Reconciliation itself. Once you load entries for a party (next section), unallocated payments populate the lower table automatically.
Payment Entry list filtered by Unallocated Amount greater than zero
Walk through the tool
Step 1: Open Payment Reconciliation
Go to Accounts > Payment Reconciliation, or search for Payment Reconciliation in the awesomebar.
Fresh Payment Reconciliation form showing Company and Party Type fields
Step 2: Set the filters
The Filters section at the top of the form scopes what NexWave will load.
Field | What to set |
|---|---|
Company | The company you are reconciling for. |
Party Type | Customer for AR allocations, Supplier for AP allocations. Other party types (Employee, Member, etc.) are supported too. |
Party | Leave blank to pull every party with unmatched activity, or pick a single party to scope the run. Per-party runs are easier to review on large datasets. |
Receivable / Payable Account | Defaults to the Company's Default Receivable / Payable Account. Override only if you are reconciling against a non-default account (for example, a separate AR account for inter-company sales). |
Default Advance Account | Visible when Book Advance Payments in Separate Party Account is on. Defaults to the Company's Default Advance Receivable / Payable Account. Advances are pulled from this account. |
Bank / Cash Account | Optional. Filters the Payments table to entries paid into or out of a specific bank or cash account. Useful when you are reconciling receipts from a particular bank. |
From Invoice Date / To Invoice Date | Scopes the Invoices table only. |
From Payment Date / To Payment Date | Scopes the Payments table only. These are independent of the invoice date filters, they are not a single reporting period. New users often set From Invoice Date and wonder why yesterday's payment is missing, set both date pairs. |
Cost Center | Optional. Limits the loaded entries to a specific cost centre. |
Accounting Dimensions Filter | Visible if your Company uses Project, Branch or any custom accounting dimension. Lets you scope to one dimension value, for example reconciling only one project's invoices and receipts. |
Invoice Limit / Payment Limit | Default 50. If a party has more than 50 open invoices or payments, the extras will not load. Set to 0 to fetch all. |
Payment Reconciliation form with Company, Party Type, Party and Receivable Account filled in
Step 3: Click Get Unreconciled Entries
Click the Get Unreconciled Entries button. NexWave populates two tables inside the Unreconciled Entries section.
Table | What appears | Source documents |
|---|---|---|
Invoices (top) | Documents that owe a balance to the party. | Submitted Sales Invoices (AR) or Purchase Invoices (AP) with outstanding amount, plus any submitted Journal Entries posted to the receivable / payable account in the opposite direction (for example, an opening balance journal). |
Payments (bottom) | Documents that have a balance sitting against the party. | Submitted Payment Entries with Unallocated Amount > 0, submitted Journal Entries posted to the receivable / payable account in the same direction as a payment, and any standalone credit notes (returns not linked to a specific invoice) or debit notes. |
Credit notes that were created against a specific invoice (the Return Against field is filled in) are auto-applied at submit and will not appear here. Only orphan credit and debit notes surface in the tool.
Unreconciled Entries section showing outstanding invoices and an unallocated payment
Step 4: Click Allocate
Tick the invoices and the payments you want to match together, then click Allocate. NexWave generates the Allocated Entries table, pairing payments to invoices FIFO (oldest invoice first) up to each payment's available balance.
A few things worth knowing:
Allocating with nothing ticked allocates everything FIFO. Both tables are treated as fully selected and the tool produces a complete proposed allocation. This is surprising if you come from Xero or MYOB. Tick the specific rows you want first if you only mean to allocate some of them.
Edit the Allocated Amount per row in the Allocated Entries table to override the default match. Lowering an amount produces a partial allocation (the rest stays on-account on the payment, the invoice stays partly outstanding). You cannot exceed the payment's remaining amount or the invoice's outstanding amount; NexWave throws a validation error citing the row number.
One payment can be split across several invoices by allocating it line by line, and one invoice can absorb several payments.
Allocated Entries table after clicking Allocate, showing FIFO distribution of one payment across three invoices
Step 5: Click Reconcile
Click Reconcile to commit the allocation.
For plain same-currency allocations the tool runs immediately. For multi-currency allocations where the invoice and payment exchange rates differ, a Select Difference Account dialog appears first, see Multi-currency allocations under Common scenarios.
What gets posted
For most allocations, no new GL postings are created. The tool writes new rows to the References table on the Payment Entry (or, for a Journal Entry on the payments side, updates the link), and NexWave recomputes each invoice's outstanding amount from those references. Open the Payment Entry afterwards and you can see exactly where the payment was applied.
Payment Entry References table showing rows that point at allocated invoices
Two exceptions write new ledger entries:
Credit note allocated to an invoice. A system-generated Journal Entry titled Credit Note (or Debit Note for AP) is posted, reducing the receivable / payable balance against the originating credit note and increasing it against the invoice.
Exchange-rate difference. A second Journal Entry is posted to the Company's Exchange Gain / Loss Account for the FX difference between the invoice rate and the payment rate.
Both of these appear under General Ledger if you need to audit the postings, and the credit-note / FX journal entries are linked back from the parent Payment Reconciliation entry.
Common scenarios
Lump-sum payment covering multiple invoices
The customer paid one amount that covers several invoices. Load the customer in Payment Reconciliation, click Get Unreconciled Entries, tick the invoices the payment is meant to cover plus the lump-sum payment, click Allocate, then Reconcile. The tool spreads the payment FIFO across the ticked invoices.
Customer overpayment or advance left on-account
A customer pays more than the invoice, or pays before any invoice exists. The extra (or the whole amount) sits on the Payment Entry as Unallocated Amount until a future invoice is raised. When the invoice is ready, run Payment Reconciliation against the customer, tick the new invoice and the unallocated payment, Allocate and Reconcile.
It is fine to leave a balance on-account intentionally (for example, a deposit against a future order). See Stale advances in Tips and gotchas for when to clean these up.
Standalone credit note sitting unmatched
A credit note was raised without the Return Against field filled (perhaps a goodwill credit, or one that covers a basket of historical invoices). It is sitting on the customer's account. Load the customer in Payment Reconciliation, the credit note appears in the Payments table; tick it together with the invoice(s) it should offset, Allocate, then Reconcile. The system-generated Credit Note Journal Entry posts the offset.
For full credit-note workflow (including how to raise one), see Refund a Customer.
Supplier prepayment applied to a bill
You paid a supplier deposit before they invoiced (a 30% prepayment for a custom order, for example). The Payment Entry sits with Payment Type = Pay and an unallocated balance. When the Purchase Invoice arrives, run Payment Reconciliation with Party Type = Supplier, tick the bill and the prepayment, Allocate and Reconcile.
Partial allocation
A payment only covers part of an invoice (the customer is paying in instalments, or the payment was short). After Allocate, edit the Allocated Amount in the Allocated Entries table down to the actual amount paid, then Reconcile. The invoice keeps its remaining outstanding balance, the payment is fully consumed (or vice versa).
Multi-currency allocation with an exchange-rate difference
The invoice was raised at one rate, the payment was received at a different rate. After clicking Reconcile, a Select Difference Account dialog opens listing each affected allocation row, the Difference Amount, a Difference Posting Date (defaults per the Posting Date Inheritance setting in Accounts Settings) and a required Difference Account (defaults to the Company's Exchange Gain / Loss Account).
Confirm the dialog. NexWave posts a Journal Entry to the Exchange Gain / Loss Account for the difference and completes the allocation. The Difference Posting Date controls which accounting period the gain or loss lands in, for year-end allocations you generally want Reconciliation Date so the gain or loss sits in the period you are reconciling.
Journal Entry on either side of the allocation
Opening balance journals, write-on / write-off journals, inter-company recharges and any other manual JE that hits the receivable or payable account will surface in Payment Reconciliation. A JE that increases the customer's debt appears in the Invoices table. A JE that reduces the customer's debt (a credit balance journal) appears in the Payments table. Allocate them like any other entry, the references update on the underlying JE rather than on a Payment Entry.
Tips and gotchas
Run per-party for large datasets. Loading every customer at once works, but the Allocate step generates one Allocated Entries row per (invoice, payment) pair and the form gets slow to review. For more than a handful of parties, run one at a time, or use Process Payment Reconciliation for a scheduled bulk run, see below.
Bulk and scheduled reconciliation. For high-volume sites (hundreds of receipts a day), use the Process Payment Reconciliation doctype, which runs the same logic across a batch of parties in the background. Auto Reconcile Payments in Accounts Settings can also reconcile payments to invoices automatically at submit when the references match exactly.
Cancelling or reversing an allocation. Payment Reconciliation does not have an Undo button. To reverse an allocation: open the Payment Entry, find the row in its References table that points at the wrong invoice, and remove it (this needs Cancel then Amend on a submitted Payment Entry). If the allocation was a credit-note reconciliation, also cancel the system-generated Credit Note / Debit Note Journal Entry. The invoice outstanding amount recomputes on save.
Cash-basis GST filers, reconcile before period-end. For invoice-basis filers, allocation has no GST impact. For cash-basis filers, GST is recognised when a payment is allocated to a taxable invoice, not when the cash hits the bank. Sitting payments unreconciled past period-end pushes output tax into the wrong period.
Write-offs and rounding differences are not handled here. If a customer pays 999.95 against a 1,000.00 invoice and you want to write off the five cents, either use the Write Off section on the Payment Entry at the time you record it, or post a small Journal Entry to your write-off account first and then reconcile both the payment and the JE against the invoice.
Stale advances. Advances sitting unmatched for more than 12 months should be reviewed. Either refund the customer (see Refund a Customer), or, if the funds are no longer refundable, recognise them as income via a Journal Entry and reconcile that JE against the advance to clear it off the customer's account.
Allocate with nothing ticked allocates everything FIFO. If you only mean to match some of the loaded rows, tick them before clicking Allocate.
Date filters are independent. From / To Invoice Date scopes the Invoices table only. From / To Payment Date scopes the Payments table only. They are not a single period filter.
Invoice Limit / Payment Limit defaults to 50. If you cannot find an entry you expected to see, raise the limit (or set it to 0 to fetch all) and re-run Get Unreconciled Entries.
Related documentation
Send Customer Statements: generate statements before chasing customers, often the first step that surfaces unallocated balances.
Refund a Customer: credit notes, refunds, and how unallocated balances become refundable.
Accounts Receivable and Ageing: report view of who owes what, with unallocated payments shown alongside.
Accounts Receivable: AR module overview.
Accounts Payable: AP module overview.
Batch Payments (Payment Run): pay multiple supplier bills in one go before reconciling.
Bank Reconciliation Tool: match bank-statement lines to or from Payment Entries. Use this before Payment Reconciliation when working from a bank import.