Why unallocated payments pile up in ERPNext and how reconciliation clears them
Unallocated payments build up in ERPNext when customer receipts or supplier payments are posted before the matching invoices exist, when a bulk bank credit covers many invoices at once, or when advances and credit notes are recorded but never linked to what they settle. Payment reconciliation is the step that matches payments, advances and credit notes to outstanding invoices so that receivable and payable ageing reflects what is really still owed. Until that matching happens, the party ledger shows open balances that finance cannot explain, and collections and supplier runs work from the wrong figures. The first decision is therefore not which tool to use, but how many unmatched items exist and whether they arrive in a steady flow or in large batches.
The ERPNext manual documents three related features on separate pages. The *Payment Reconciliation* tool matches open payments and advances against outstanding invoices for one party and account at a time, which suits a small volume or a single customer with a complex history. The *Process Payment Reconciliation* tool works on a larger set of parties and runs as a background job, which suits month-end backlogs or a bank feed that produced many receipts in one day. The *Unreconciliation* feature cancels allocations that were made in error so the entries can be matched again. Teams should read all three pages before they clear a backlog, because the unreconciliation step is the one that undoes work already done.
Before running either tool, confirm with your accounts team which accounts, cost centers and currencies the open items use, and whether any advances belong to a company other than the one you are reconciling. Test the sequence on a copy of production data, check the ageing report afterward, and agree who may approve unreconciliations. The exact behaviour of each tool depends on the ERPNext version you run, so confirm the current steps on the linked manual pages and in your own test environment before you change live balances.
Which reconciliation tool fits which volume and situation
ERPNext treats the Payment Reconciliation tool, the Process Payment Reconciliation tool and unreconciliation as separate decisions, each suited to a different volume and situation. Choosing among them depends on how many open items a party has, whether you are working interactively or in batch, and whether a match needs to be undone.
Payment Reconciliation for one party
Use the Payment Reconciliation tool when you are working through a single customer or supplier's open items interactively. You select the party, review the unallocated payments, advances and credit notes alongside the outstanding invoices, and match them by hand. Before you start, confirm in your version which party types and voucher types the tool lists, since the documented scope may differ from what your site shows.
Process Payment Reconciliation for batches
The Process Payment Reconciliation tool is the separate option for larger volumes, where you set filters and run matching across many parties or vouchers in one pass. Teams with a large backlog of unallocated items usually plan a batch run rather than working each party in the interactive screen. Confirm in your version whether the run executes in the background, how it reports failures, and how it handles items that do not match.
Unreconciliation for reversing a match
Use the unreconciliation feature when a payment or credit note was allocated to the wrong invoice, or to the right invoice in the wrong amount. Reversing the match restores the open balances so you can allocate again. Check the accounting period and the status of the linked vouchers before reversing, and confirm in your version which document types can be unreconciled.
Payments and advances
Customer payments and supplier payments create unallocated amounts that the tools can match to outstanding invoices. Advances, such as a customer deposit recorded before an invoice exists, follow the same logic but leave a balance on the party account until allocated. Confirm how each advance type appears in the tool's lists in your version, and whether a partial allocation leaves the remainder open for later matching.
Credit notes and returns
Credit notes and sales or purchase returns reduce the outstanding balance of the invoices they relate to. Reconciling them is a different decision from reconciling cash, because a wrong match changes the party's ageing and may affect tax reporting. Ask your accountant which credit note types should be matched against which invoices, and confirm in your version how returns are listed in the tools.
Scope and version checks
Before you choose a tool for production, test it on a copy of your data with a representative set of parties. Record which voucher types each tool lists, how it treats multi-currency items, and what it does with items that partly match. Your implementation partner or internal team should confirm this behavior against the exact ERPNext version in use, because documented scope can change between releases.
Configuration options and when each fits
This table compares manual matching per party, background reconciliation of many entries and unreconciling by volume, control needs and the accounting staff who run each one. Read it by first deciding how many unallocated payments you clear each cycle, then checking which control level your auditors and finance leads expect. The main takeaway is that speed and per-entry review pull against each other, so most teams use more than one approach.
| Approach | What it needs from accounting staff | Control and review trade-off | When it fits |
|---|---|---|---|
| Manual matching per party | An accountant selects the party, reviews open payments and invoices, and allocates amounts before submitting | Highest per-entry review. Each allocation is visible and deliberate, but the work scales with the number of parties | Low volume, unusual advances, or parties with disputed or partial payments |
| Background reconciliation of many entries | A lead defines filters for party, account and date range, then reviews the outcome and any entries that were not matched | Faster for large volumes, but reviewers see results after processing rather than choosing each match | High volume of similar payments where filters can be set tightly and results are checked afterward |
| Unreconciling a mistaken allocation | A senior accountant identifies the entry, confirms the period is open and approves the reversal | Corrects errors without deleting documents, but affects ledgers and reports, so access should be limited | Fixing wrong matches discovered during review or bank checks |
| Period status and locking | A controller confirms that the period is open or closed before any allocation or reversal | Protects closed periods from late changes, but may block corrections until the period is reopened under your rules | Month-end and year-end close, when reconciliation must be final |
| Reviewer sign-off | A second person checks matched and unmatched lists, and records approval in your process documents | Adds a control step that assessors look for, but adds elapsed time to each cycle | Regulated entities or teams with segregation of duties requirements |
| Permissions and roles | An administrator decides which users can run reconciliation, process in background or unreconcile | Narrow roles reduce risk but can create bottlenecks if only one person can act | Any site where payments and invoices are handled by different teams |
Setting up reconciliation without mismatching the ledger
This sequence confirms the accounts and vouchers in scope, proves the matching logic on one party, and only then scales to batch runs. The output is a ledger and ageing view that you have checked before any bulk posting happens.
Confirm receivable and payable accounts
Before any matching, the finance lead and the ERPNext administrator confirm that each Customer and Supplier points to the correct receivable or payable account, and that advances and unallocated payments post to the accounts the company expects. Check the party accounts table on each Company and the default accounts on the party masters. Done means every party type in scope maps to one account per company, with no account shared by mistake across customers and suppliers.
Define which vouchers are in scope
Agree the list of document types that the reconciliation may touch: sales invoices, purchase invoices, payment entries, journal entries used for advances, and credit notes. Record which of these are allowed to be matched automatically and which need a reviewer's sign-off. Mark any voucher type that should stay out of the run, such as manually posted journals with no party reference. Done means the agreed list is written down and the reviewer knows which exceptions they own.
Snapshot the party ledgers before changes
Run the General Ledger and the Accounts Receivable and Accounts Payable ageing reports for the test scope, then export or note the outstanding amounts for the sample parties. Save the totals per party and per account so they can be compared later. Done means you hold a dated baseline that shows what each test party owes or is owed before any reconciliation entry is created.
Reconcile one party as a test
Choose one customer with a payment, an advance and at least one open invoice, then open the Payment Reconciliation tool, select that party only, and allocate the unallocated amount against the intended invoice. Use the preview to confirm the allocation before you submit. Done means the allocation matches the amounts the finance team expects, with no residual difference on the party ledger.
Verify the ledger and ageing after the test
Reopen the party ledger and the ageing report and compare them with the baseline. The invoice outstanding should fall by the allocated amount, the unallocated payment should drop by the same amount, and the General Ledger should show no new entries outside the expected voucher pair. Repeat the check for one supplier if the scope includes payables. Done means every movement is explained and the test party balances agree to the penny with the source documents.
Correct test mistakes with unreconciliation
If the test allocation is wrong, use the unreconciliation feature on the affected voucher rather than editing the ledger by hand, then repeat the test with the corrected allocation. Record each correction and the reason in your change log. Done means the test party returns to its baseline or to the corrected state, and the reviewer has signed off the reversal in writing.
Scale to batch processing with checks
Move to the Process Payment Reconciliation tool and run it for a small batch of parties or a single date range, rather than the whole customer base. Confirm the background job completes, then compare the batch totals with the ledger and ageing baseline for those parties. Confirm the expected batch size with your DeployOpen and ERPNext administrators, since run time depends on your data volume and infrastructure. Done means each batch closes with totals that agree with the ledger, before the next batch starts.
How ERPNext matches an advance to an invoice
Reconciling an advance in ERPNext reduces the outstanding amount on both sides of the match, and the party ledger then shows the invoice as partly or fully settled. The unallocated payment or credit note keeps its own record and its remaining unallocated balance, while the sales or purchase invoice carries a lower outstanding amount. Before anyone runs the Payment Reconciliation tool, the team should confirm how the accounts receivable or payable ledger for that party will read after the match, because the reporting depends on that reduction being posted against the right party account and currency. The ERPNext Payment Reconciliation documentation describes the matching screen and the entries it creates, and the finance lead should walk through one example with the actual chart of accounts before the first live batch.
An advance, a payment spread across several invoices and a credit note are all matched against outstanding documents, but they behave differently in practice. A single payment can be allocated to several invoices, and a single invoice can be settled by several payments or credit notes, so the reconciliation view should be checked against each document's remaining balance rather than assumed. Allocation amounts cannot exceed what is still open on either side. Teams should decide in advance how they will handle partial allocations, short payments and credit notes issued against a different invoice than the original sale, and confirm each case in a test company first (the exact behavior for each document type should be checked against the version in use).
Controls and permissions for reconciliation work
Reconciliation changes which invoices are settled and by how much, so it touches cash, receivables and payables at once. The cards below cover the four areas to design before go-live: who can match and unmatch, what evidence each match leaves, how closed periods are protected, and how recording and matching are split between people.
Who may reconcile and unreconcile
Matching and unmatching are separate actions in ERPNext, and both depend on the roles and permissions granted to each user. Decide which roles can run the Payment Reconciliation tool and which can reverse a match before anyone is trained. Test the configuration with a non-administrator account, since administrators often bypass restrictions that finance staff will hit.
Audit trail of matches
Each allocation links a payment to an invoice, credit note or advance, and the reversal of that link is a separate event. Ask who must be able to see the history of an allocation, how long it is kept, and whether a reviewer can reconstruct why an invoice was closed on a given date. Check this against your own retention policy, not only the default settings.
Period locking for closed periods
A match or unmatch posted into a closed period changes results that were already reported. Confirm how your site restricts posting to closed periods, such as accounting period locks or a frozen date, and who may change that setting. Agree the reopening rules with the controller before the first close runs, so reconciliation is not used as a way to adjust old periods.
Separating receipt entry from matching
The person who records a receipt should not also decide which invoice it settles, particularly when an unallocated payment is later applied to an old balance. Map which roles can create payments and which can allocate them, and review any user who holds both. Where one person must do both in a small team, plan a second reviewer for matches above an amount you set.
Background runs and their owners
Large reconciliations can run as background jobs, which means the person who started the run may not see its result immediately. Decide who monitors these jobs, who receives failure notices, and who may re-run them. Confirm that a re-run cannot allocate the same payment twice, and test this on a copy of production data first.
What does reconciliation cost and what does the work need from us?
What drives the cost of ERPNext payment reconciliation work?
The scope drives the cost more than the tool does, because ERPNext's Payment Reconciliation tool is part of the platform you already pay for in effort, not a separate license. The main effort drivers are the number of parties with open items, the volume of unallocated payments, advances and credit notes, the currency mix, the number of companies on the site, and how clean the existing data is. Each one adds review time, rule design and testing. Self-hosting ERPNext is free according to the ERPNext pricing page, so your cost basis is staff time, infrastructure and any partner fees.
Which reconciliation work is one-time and which recurs every month?
One-time work includes configuring accounts and default settings, cleaning up historical open items, testing matching on a copy of your data, and training the people who will match payments. Recurring work is the monthly matching cycle, reviewing unreconciled items, handling new advances and credit notes, and checking that reconciliations stay correct after period close. Ask a partner to separate these two groups in the quote so you can see what your team will carry after go-live.
Can our internal finance team run payment reconciliation alone?
Often yes, if at least one person understands your receivables and payables process and has access to a test site. The Payment Reconciliation tool and the unreconciliation feature are documented in the ERPNext manual, so a trained accountant can run them for routine volumes. Teams usually need outside help when they have a large backlog of old open items, many companies or currencies, or custom rules for matching, and when they lack anyone to own the setup and the testing. Decide this on the size of your backlog and the number of people who can review the results.
What should we ask a partner for in a fixed-scope reconciliation quote?
Ask for a written scope that lists the companies, currencies, party groups and payment types in scope, plus the data you will provide and the environments used for testing. The quote should name the deliverables, such as configured settings, a tested matching procedure, a written monthly runbook and staff training, and state what is excluded. Ask how historical open items will be handled, what acceptance criteria apply, and who signs off. DeployOpen plans most engagements as fixed scope with these items agreed in writing before work starts.
How long does reconciliation work take?
The duration depends on the scope, not on a standard timeline. A single company with clean data and one currency takes far less time than several companies with a large backlog of unallocated payments, credit notes and advances in multiple currencies. Ask for a timeline tied to the listed deliverables and to your availability for testing and sign-off. Any duration in a quote should follow from the agreed scope and the data review, not from a generic estimate.
What do we need to provide before reconciliation work starts?
You need to provide a sample or copy of the data to be reconciled, a list of open invoices, payments and credit notes with their parties and currencies, the chart of accounts and bank accounts in use, and the current matching practice your team follows. Name the person who approves matching rules and the person who signs off the results. Access to a non-production ERPNext site is needed for testing before any change touches live accounts. Confirm the ERPNext version you run, because supported versions and their release cadence determine which tool behaviour you test against.
Does the platform cost change if we move to a hosted Frappe Cloud plan?
Your platform cost changes with the hosting choice, but reconciliation effort does not disappear. The ERPNext pricing page lists the cost basis, including that Frappe Cloud shared site hosting starts at 5 US dollars per month and dedicated servers start at 125 US dollars per month. Those figures are list prices from that page and may have changed, so check them on the pricing page before budgeting. Note that Frappe's supported versions policy ties warranty coverage to a listed version and a matching support plan, which affects the ongoing support decision.
Undoing a wrong match without corrupting the ledger
The documented way to reverse a wrong match in ERPNext is the Unreconciliation feature, not a manual edit to the payment or invoice. Use it to detach a payment, advance or credit note from the invoice it was matched to, then run the Payment Reconciliation tool again with the correct pairing. Because the reversal is a documented step, the original journal entries stay in place and the correction is traceable. Before you start, confirm in your own environment which voucher types the Unreconciliation page accepts and whether your ERPNext version handles advances and credit notes the same way, since the manual describes these as separate pages and the behavior should be tested on a copy of your data first.
After the unreconciliation, check three things. The outstanding amount on the invoice should return to its pre-match value, so the Accounts Receivable or Accounts Payable ageing report should show the invoice open again with its original due date. The unallocated amount on the payment or advance should show the released value, ready for the corrected match. Then open the General Ledger for the affected accounts and confirm that no new postings were created beyond the expected reversal of the allocation. If the ledger shows changes you did not intend, stop and investigate before reconciling anything else, because later matches built on the wrong state are harder to unwind.
Set a reconciliation review rule before period close. Name one owner for the unreconciled payments list, usually a senior accountant outside the team that posts receipts, and require a second person to approve any unreconciliation. Schedule the review ahead of the closing date and record who approved each correction. Expect that a closed accounting period, or a frozen date set on the company, can block a reconciliation or unreconciliation dated in that period. Confirm with your controller how reopening a period is authorized in your setup, and plan corrections for an open period rather than asking for a reopen under deadline pressure.
How DeployOpen scopes and delivers reconciliation setup
Reconciliation setup is scoped in writing before any configuration starts. DeployOpen works from a written scope that names the parties in play (customers, suppliers and employees who make advance payments), the currencies and bank accounts involved, the companies on the site, and the expected volume of payments, advances and credit notes per period. Those inputs decide whether the work is a manual Payment Reconciliation exercise, a set of process rules, or a background reconciliation design for large batches. Each scope item is tied to a deliverable so that the cost and timeline can be checked against what is actually built.
The written scope also fixes the configuration and controls. Typical items include the accounts that unallocated payments post to, the Payment Reconciliation filters each finance role will use, the permissions that let accountants reconcile but not post unrestricted journal entries, and the unreconciliation rule that governs when a match may be reversed. DeployOpen runs test reconciliations on sample data copied from your environment or prepared for the purpose, checks the ledger and ageing reports after each run, and records the results. Confirm with your own finance team whether test data may leave your environment and which data-protection terms apply before sample data is shared.
Handover covers the reconciliation runbook, the configuration record, test evidence and a list of known exceptions. Ongoing matching, rule changes and ERPNext upgrades can be covered by an optional retainer, which is agreed separately from the fixed-scope build. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the cost components to be itemized: scope and configuration, testing, handover, and any recurring support, and ask which items depend on volume, number of companies or currencies.
