Supplier Prepayment Reconciliation for AP Teams

A supplier advance has left the bank. The first delivery invoice arrives, followed by a second. If accounts payable pays both invoices in full while the advance stays open, the bank reconciliation can still balance—even though the supplier has received too much.

Supplier prepayment reconciliation connects the paid advance to its approved invoice applications, reversals and remaining balance. The output is a document-level clearing record that agrees with the accounting system, not simply a payment confirmation or a supplier’s statement.

Begin after the advance is paid

Use this process for an existing supplier advance that will be applied against later invoices. Decide whether to grant the advance through the separate supplier advance approval process. Here, the question is what happened to the money already advanced.

Keep three facts separate: cash paid, advance still available, and invoice balance still payable. Infor’s prepayment example shows a down payment applied to a later invoice so only the remainder is paid. Its journal entries are product-specific; the control lesson is to demonstrate the application rather than assume the advance reduced the bill.

The following workflow is a recommended internal control, not a universal accounting rule or statutory deadline: Paid advance → Identified → Application proposed → Reviewed → Posted → Reconciled → Closed. An unapplied residual remains open even when an individual invoice is settled.

Establish the balance that is actually available

AP creates one reconciliation record for the advance, identifying supplier account, legal entity, currency, contract or PO, payment reference, original advance document and accounting posting. Treasury confirms the payment from bank evidence; the contract owner confirms the deliveries or milestones the advance can cover.

Start from the last approved balance, not from the original payment amount each time. Retrieve all subsequent applications, reversals, refunds and other authorized adjustments from the accounting system. An application already used on another invoice is not available again.

• AP preparer: assembles documents and proposes application amounts.
• Business owner: confirms accepted delivery and the contractual basis for using the advance.
• Accounting reviewer: approves treatment, period and posting evidence under company policy.
• Payment releaser: checks the approved net invoice balance before sending further cash.

Separate preparation and review where feasible. Where staffing is limited, designate an independent reviewer and record what they checked. This is a recommended control design, not a claim that every organization has the same staffing requirement.

Build an advance-to-invoice allocation bridge

Use one line per application, with the advance ID, invoice ID, contract or PO reference, invoice amount, advance available before application, proposed amount, posting reference and reviewer. Preserve both document IDs even if the supplier uses the same reference on several bills.

The following example is illustrative USD, with no tax, fees, exchange differences, other credits or prior invoice payments. A supplier has received a $6,000 advance for a $10,000 engagement. The agreed application schedule uses $2,500 on the first accepted milestone and $3,500 on the second.

Cash paid across the engagement is $6,000 in advance plus $4,000 later: $10,000, not $16,000. At the first milestone, the invoice can be fully settled after its $1,500 payment while $3,500 of the advance remains open. Those are different balances with different closure conditions.

For this simplified example, invoice amount minus approved advance application equals additional cash due. In real cases, AP must also reconcile previous payments, credit documents, withholding and other supported adjustments. Do not use the simplified formula to override the approved invoice ledger.

Review, post and verify the application

Approve the allocation, not just the total

Confirm that the supplier, entity, currency and contractual purpose match. Check the invoice’s approval and delivery evidence independently; having an advance does not prove that the invoice is correct. Reject applications exceeding either the available advance or the eligible invoice balance.

Microsoft’s Dynamics 365 guidance distinguishes one-invoice and multiple-invoice cases, including failures when the prepayment exceeds the invoice amount. Those are specific software behaviors, not universal rules. They illustrate why a failed automated application needs an explicit review rather than an assumption that it succeeded.

Require accounting-system evidence

Accounting applies the advance using its approved system procedure, verifies the period and accounts, and returns application and posting references. Do not treat a spreadsheet allocation or approved workflow as proof of a posted transaction.

MYOB’s prepayment documentation distinguishes the original payment from the open advance and describes application history. Status labels differ by system: a payment marked Closed does not, by itself, prove that the advance has been fully consumed.

Check the final payment proposal

The payment releaser compares the invoice’s remaining balance with the posted application and approved payment proposal. If an application was removed, changed or reversed after approval, return the affected proposal for review. Do not silently increase the cash payment to make the invoice close.

Roll forward the residual and preserve reversals

For each advance, reconcile: opening unapplied balance + new paid advances + reversed applications − posted applications − confirmed refunds ± separately approved other movements = closing unapplied balance. Define the signs and supporting documents consistently; refunds belong here only when the accounting record actually reduces this advance.

Keep the same currency and accounting basis throughout each roll-forward. Where base-currency remeasurement or currency conversion is relevant, accounting should reconcile those movements separately and approve their treatment. A currency difference is not an unexplained application.

Suppose INV-201 is canceled after its $2,500 advance application was posted. If accounting reverses that application, $2,500 becomes available on the advance again. Retain both the original application and its reversal; do not delete the original row or count the advance as consumed. Separately investigate the invoice’s $1,500 cash payment and any recovery needed. Reversing an application does not return cash to the bank.

Approve any new application of that $2,500 through the normal review path. An earlier approval for a canceled invoice is not authorization to apply it to an unrelated bill.

Resolve exceptions without forcing a zero

• Partial delivery: the business owner confirms accepted work; AP applies only the supported amount and retains an owner and expected clearing date for the rest.
• Missing final invoice: AP follows up with the supplier and contract owner. Do not create a fictitious invoice to clear the balance.
• Supplier proposes a refund: record the claim and follow the approved refund process. A promise does not equal received cash or a posted reduction.
• Wrong supplier or entity: block application and ask accounting to approve the correction. Similar names and equal amounts do not establish identity.
• Automated application failed: retain the error, assign an owner, and confirm the corrected posting before releasing the affected payment.
• Old or disputed residual: escalate under company aging policy. Accounting determines whether recovery, reclassification or another approved treatment is appropriate; age alone is not permission to write it off.

Close the reconciliation, not just the worksheet

At the company’s chosen close cadence, AP ties the application register to the advance detail and accounting control balance. Each open amount needs an explanation, owner, next action and due date. Keep an unresolved difference visible rather than adding an unsupported balancing adjustment.

The reviewer signs off on the opening balance, movements, closing balance, invoice residuals and posting references. Feed the supported result into the broader accounts payable reconciliation. A period’s reconciliation may be approved with a valid open advance; the advance itself closes only when its balance is fully applied or otherwise resolved through approved, posted treatment.

Where Workhint fits

The coordination task is collecting the proposed allocation, delivery support, reviewer decision and posting reference before the payment handoff. Workhint’s Workflow Engine describes role-based approvals and requirements for details, files and notes before work progresses. These are relevant building blocks for an application-review workflow.

The Finance Leaders solution describes connected invoice and payment review and approval. Discuss how the proposed advance-review steps would be configured, rather than assuming a prebuilt reconciliation module. These pages do not establish automatic advance allocation, bank imports or posting into your ledger; accounting and bank evidence remain authoritative.

Frequently asked questions

Is reconciling an advance the same as reconciling its bank payment?

No. Bank matching establishes the cash movement. Advance reconciliation establishes how that value was applied and what remains unapplied.

Can one advance cover more than one invoice?

Where the contract and accounting system permit it, yes. Maintain separate application lines and prevent their total from exceeding the available advance.

Does an open advance always mean a close error?

No. It may relate to future delivery. The reviewer needs support for the balance, its owner and expected clearing event. An unexplained or overdue amount needs action, not automatic clearance.