Match a partial customer payment by using its reference and confirmed customer identity to find candidate invoices, then checking how much can be allocated against each current balance. Do not choose an invoice simply because its total looks similar. Keep uncertainty visible and ask finance to approve the allocation before any accounting record changes.
This is a customer receipts workflow, not supplier accounts payable. The proposed process below prepares evidence for finance review. It does not authorise payments, decide write-offs or replace professional accounting judgement.
1. Establish what the receipt actually proves
Start with the received transaction, not the invoice you hope it belongs to. A proof-of-payment attachment can support an investigation, but the review should distinguish that document from a receipt confirmed in the business's bank or accounting records.
The proposed intake record should capture:
- The source transaction identifier and receiving account.
- Receipt date, amount and currency.
- Original bank reference and payer description.
- Any remittance advice and its source.
- Whether the receipt is confirmed, pending or already recorded.
- The amount still available for allocation.
Preserve the original reference alongside any cleaned version. Removing spaces may help comparison; removing every prefix or leading zero could turn different references into the same value.
Record missing information as missing. Do not infer a customer identifier from a familiar trading name without supporting records. If the bank import has no stable transaction identifier, finance and the integration team should agree how to identify receipts consistently before proceeding.
This narrow preparation task fits accounting automation: organise receipt evidence, propose allocations and hand the decision to finance.
2. Retrieve the right invoice population
Search within the confirmed business entity and customer account before widening the search. The proposed default is to retrieve outstanding customer invoices in the relevant currency, along with their current balances and existing allocation information.
Build a review snapshot containing the invoice identifier, displayed invoice number, customer identifier, reference, status, currency, outstanding amount and retrieval time. These are proposed review fields, not a promise that every connector supplies them unchanged. Validate the mapping against the accounting system your team uses.
The Source: Xero Accounting API definition includes examples of payments associated with invoice identifiers, payment amounts and bank amounts. That supports checking linked records, but does not establish a native partial-payment matching process.
Do not treat the bank amount and invoice-currency amount as interchangeable. Route foreign-currency cases to finance for exchange-rate and accounting treatment decisions.
If a reference points to a closed or otherwise ineligible invoice, retain that finding as a conflict. Silently excluding it would hide useful evidence of an earlier allocation, incorrect reference or disputed account history.
3. Generate candidates from reference and amount evidence
Use references to identify candidates and amounts to check whether a proposed allocation is feasible. Partial payments make exact total matching a weak starting point: a receipt can legitimately be smaller than the invoice balance.
Use this proposed candidate sequence:
- Compare the original and safely normalised reference with invoice numbers and references.
- Confirm that the candidate belongs to the identified customer and business entity.
- Check currency and current outstanding balance.
- Read remittance advice for explicit invoice instructions.
- Retain plausible alternatives and explain why they remain unresolved.
An amount that fits several balances does not identify the intended invoice. Nor does the oldest due date prove customer intent. Finance can adopt an allocation policy, but the screen should label policy-based suggestions separately from customer instructions.
Use fixed comparison rules for identifiers and arithmetic. Where remittance text varies, a bounded extraction step may help organise it. The AI agents versus automation comparison provides context for deciding which parts need interpretation and which should stay rule-based.
4. Represent uncertainty instead of hiding it
Present reasons and contradictions, not an unexplained confidence percentage. A reviewer needs to see why one invoice is proposed and what evidence could change that proposal.
Proposed evidence labels include “exact invoice reference”, “customer confirmed”, “remittance instruction present”, “reference incomplete” and “payer differs from customer”. Multiple labels can apply to the same candidate. A strong reference match should not erase a currency conflict or duplicate warning.
For text extraction, define fields such as extracted invoice references, stated allocation amounts, evidence locations and unresolved questions. Allow empty results rather than requiring the model to name an invoice.
Source: OpenAI Structured Outputs supports schema-constrained responses and describes refusal and incomplete-response handling. A correctly shaped response still needs factual checks against the receipt and invoice records.
Treat remittance documents as evidence, never as authority to bypass review. A document saying “allocate immediately” is not an application instruction. A custom AI agent, if used here, should have bounded access and produce review material rather than decide the accounting outcome.
5. Calculate the proposed allocation and remainder
Calculate both sides of the allocation: what remains on the receipt and what remains on the invoice. The proposed control is that allocations must not exceed either the available receipt amount or the applicable invoice balance.
For each candidate, show:
- Current outstanding invoice amount.
- Proposed allocation amount.
- Expected invoice balance after allocation.
- Expected unallocated receipt amount.
- Any assumptions or missing evidence.
Use decimal-safe calculations and verify the currency of every value. Do not ask a language model to supply authoritative ledger arithmetic.
If a receipt covers several invoices, present an explicit allocation line for each invoice. Do not search for combinations of balances and declare a match just because the sum fits. Require remittance instructions or a finance-approved rationale for the split.
Leave differences unresolved unless finance approves their treatment. Bank charges, discounts, credit notes, exchange differences and write-offs require appropriate accounting and, where relevant, tax judgement. The proposed workflow must not manufacture an adjustment to make the receipt appear fully allocated.
6. Put approval behind a clear review boundary
Finance should approve a specific allocation proposal, not a vague recommendation to “match this payment”. The approval record should identify the receipt, invoices, allocation amounts, evidence snapshot and reviewer rationale.
Separate review from execution. Source: OpenAI's function-calling guide explains that the application executes code in response to model tool requests. In this proposed design, the application should allow candidate retrieval and review preparation without granting the model authority to change finance records.
Source: n8n's human-review documentation describes pausing selected tool calls for approval or denial. That is a possible implementation component, not proof that a complete payment-allocation control exists out of the box. Confirm connector behaviour and access requirements before selecting tooling.
Before any approved posting step, refresh the receipt's available amount and invoice balances. If either changed, return the proposal for review. Denial, timeout or an unavailable reviewer should leave the case pending, not trigger a fallback allocation. Finance and security owners should approve access, retention and reviewer permissions.
Payment-allocation review screen brief
Use the following proposed brief to specify the screen and its acceptance checks.
Purpose: Prepare a partial customer receipt allocation for finance approval. No automatic allocation approval or posting.
| Screen area | Required content or behaviour |
|---|---|
| Receipt header | Source ID, receiving entity, date, currency, confirmed amount, available amount, raw reference and payer description. |
| Evidence panel | Bank record and remittance links, extraction source locations, missing fields and retrieval time. |
| Candidate table | Invoice ID and number, customer, currency, current balance, supporting evidence and conflicts. |
| Allocation editor | Proposed amount per invoice, remaining invoice balances and unallocated receipt amount. |
| Exception panel | Missing reference, competing invoices, payer mismatch, currency mismatch, duplicate suspicion and stale records. |
| Reviewer actions | Approve proposal, edit and approve, reject candidates, request clarification or hold. Require a reason for edits and exceptions. |
| Decision record | Reviewer, time, evidence snapshot, approved allocation lines and rationale. Keep posting status separate. |
Proposed gates: Block approval for invalid arithmetic, unavailable balances or unresolved duplicate identity. Revalidate balances and receipt availability before posting. Changed evidence requires renewed review.
Acceptance checks: A partial allocation leaves the correct remainder; competing candidates stay visible; repeat imports do not create another allocation; rejected and held cases remain unresolved; every approved proposal has attributable evidence and a reviewer.
Worked walkthrough: normal, ambiguous and duplicate receipts
The following records and amounts are entirely hypothetical. They illustrate expected review handling, not results from an implemented system.
Normal case: A confirmed ZAR receipt of R4,000 carries reference INV-1042. The confirmed customer has an outstanding balance of R10,000 on INV-1042. Remittance advice names that invoice and describes the payment as an instalment. The proposed allocation is R4,000, leaving R6,000 outstanding and no unallocated receipt amount. Finance checks the evidence and approves the proposal. Posting remains a separate controlled step.
Ambiguous case: Another hypothetical R4,000 receipt carries only the customer's trading name. That customer has two outstanding invoices, each with a R6,000 balance. Both can accept the receipt, so amount evidence cannot distinguish them. The screen shows both candidates without selecting one. Finance requests remittance advice or applies an explicitly approved allocation policy, recording the rationale. Until then, the case stays unresolved.
Duplicate case: A later import contains the same source transaction identifier as the normal case. The proposed duplicate gate blocks a second allocation and links the existing case. If identifiers differ but the date, amount and reference resemble the earlier receipt, flag suspicion rather than declaring a duplicate. Finance checks whether there were genuinely two receipts.
7. Evaluate the review process before expanding it
Evaluate candidate quality and exception handling with finance-labelled examples before allowing the workflow near posting permissions. Include partial instalments, absent references, reused references, split receipts, already allocated payments and balance changes during review.
Agree proposed acceptance criteria in advance. Measure how often the correct invoice appears among candidates, how often an incorrect candidate is presented as the preferred option, and how often reviewers must correct amounts or retrieve missing evidence. Record unresolved cases rather than counting them as successful matches.
Test operational failures too: unavailable records, incomplete extraction, rejected approval requests and repeated imports. Confirm that each failure leaves a visible pending case with an owner and reason.
The custom AI agent workflow resource can inform the wider workflow design. Any potential benefit should be evaluated against the team's current review process, including review effort and correction work, rather than assumed from vendor capability.
If your business needs help defining this boundary, Symaxx's AI automation services can support the planning discussion. Get in touch with a proposed receipt sample and exception list, using redacted information rather than live customer banking details.
FAQs
These answers apply to the proposed finance-review workflow, with final allocation treatment left to authorised finance staff.
Can we match a partial payment when the bank reference is blank?
Yes, you can create candidates from a confirmed customer account and supporting remittance evidence. Without an invoice reference, amounts usually establish feasibility rather than intent. Show every plausible candidate and ask finance to obtain clarification or use an approved allocation policy. Do not silently choose the oldest invoice or invent a reference to fill the gap.
What if the customer says the receipt covers several invoices?
Create separate proposed allocation lines and compare them with the customer's remittance instructions. Check that their total does not exceed the available receipt amount and that each line fits the relevant outstanding balance. Show any remainder explicitly. If the instructions conflict with current records, finance should resolve the discrepancy before approving the split.
What should happen if an invoice balance changes after approval?
Return the proposal for renewed review rather than posting against the old snapshot. Another receipt, credit or adjustment may have changed what can be allocated. Preserve the original decision for traceability, retrieve the current balance and show the difference. Finance should approve the revised allocation, and the application should check receipt availability again before any posting step.