How to Handle Supplier Advance Payments and Deposits in Accounts Payable

Standard accounts payable assumes an invoice arrives before payment. Advance payments invert that, and most AP processes have no clean way to handle it β so the deposit gets recorded loosely or not at all. When the supplier later invoices for the full contract value, nothing links the two and the full amount gets paid. Fix it by recording every advance as an asset against a specific supplier and reference, requiring a supporting document, and netting it against the final invoice automatically rather than by memory.
Why Advance Payments Break Normal AP
Accounts payable is built on a fixed sequence: goods or services are delivered, the supplier invoices, the invoice is matched and approved, payment is made. Every control in the process β three-way matching, approval routing, duplicate checking β assumes the invoice comes first.
Advance payments reverse it. Money moves before any invoice exists.
That single inversion disables most of the control framework at once. There is no invoice to match, no purchase order line to consume, no receipt to verify against. The payment has to be authorised and recorded on some other basis, and most AP processes have no well-defined alternative β so it gets handled as an exception, which in practice means handled inconsistently.
When advance payments happen
They are far more common than most finance teams assume:
- Deposits on large orders β typically 20β50% before production begins
- Mobilisation payments on construction and project work
- Full prepayment where a supplier extends no credit to new customers
- Retainers for professional services
- Bookings and reservations β venues, equipment hire, freight capacity
- Import transactions, where payment precedes shipment as standard practice under the delivery and payment terms codified in the ICC Incoterms rules
Any business that buys custom-manufactured goods, commissions project work, or imports will encounter these regularly.
What Actually Goes Wrong
The payment is requested by email, with no document at all
This is the most damaging pattern, and it is common. A budget holder emails finance asking for a deposit to be paid to a supplier so work can start. There is no invoice, and often no proforma invoice either β sometimes just a contract or an email thread.
Finance pays it because the request is legitimate and the work is urgent. But there is nothing structured to record it against. No invoice number, no document reference. The payment exists as a bank transaction and, at best, a note in a spreadsheet.
Where no document supports the advance, the entire netting-off process afterwards has to be handled manually β which means it depends on somebody remembering, months later, that the deposit happened.
The supplier invoices for the full amount
This is the mechanic behind most losses.
Suppliers generally issue the final invoice for the full contract value, not the outstanding balance. A S$100,000 order with a S$30,000 deposit paid results in a final invoice for S$100,000, not S$70,000.
If the deposit was recorded independently β or only as a bank line β nothing connects the two. AP receives an invoice for S$100,000, matches it to a S$100,000 purchase order, and it passes every check. The organisation pays S$130,000 for a S$100,000 order.
Duplicate detection does not catch it, because the two payments differ in amount, date and reference. There is no duplicate. There is an unapplied advance, which is a different problem that standard controls do not look for.
Advances are never reviewed for ageing
An advance is an asset β value the supplier owes you. But it sits in a prepayment account nobody reviews.
If the supplier never delivers, delivers partially, or goes out of business, that asset is impaired. Because prepayment accounts are rarely aged the way receivables are, impairment can sit undetected for years. An unrecovered advance is effectively an unmonitored loan to a supplier.
The GST or VAT is stranded
Where an advance is supported only by a proforma invoice, the tax element is usually not reclaimable until the final tax invoice arrives. Some regimes take the opposite view and treat receipt of an advance as creating a tax point β compare HMRC VAT Notice 700 with IRAS GST guidance before assuming either treatment. On a large deposit this can strand a meaningful sum for months. Teams that assume tax is recoverable at payment often find it clawed back at review.
Approval is weaker than for normal invoices
Because advances bypass the invoice flow, they frequently bypass the approval matrix too β routed as a payment request rather than a payable. Advance payments are often the largest single disbursements a business makes, and they can end up with the least scrutiny.
How Should Advance Payments Be Handled?
1. Require a supporting document β always
No advance should be paid against an email alone. Require at minimum a proforma invoice, a signed contract with a payment schedule, or a formal down payment request.
This is not bureaucracy. The document supplies the reference that makes everything downstream possible: what the advance relates to, what the total contract value is, and what should eventually be netted off. Without it, recovery depends on human memory.
Where a supplier will not issue a proforma invoice, a contract clause specifying the deposit and the total is an acceptable substitute. What is not acceptable is nothing.
2. Record it as an asset, not an expense
The accounting treatment is straightforward but frequently done wrong:
On payment of the advance:
| Account | Debit | Credit |
|---|---|---|
| Supplier advances (asset) | 30,000 | |
| Bank | 30,000 |
On receipt of the commercial invoice for the full value:
| Account | Debit | Credit |
|---|---|---|
| Expense or inventory | 100,000 | |
| Accounts payable | 100,000 |
On application of the advance:
| Account | Debit | Credit |
|---|---|---|
| Accounts payable | 30,000 | |
| Supplier advances (asset) | 30,000 |
Balance payable: 70,000.
The key point is that the advance never touches expense. This follows the same logic as IFRS 15, under which consideration paid before performance is a balance-sheet item rather than a profit-and-loss one. It converts from one asset (cash) to another (a claim on the supplier), and is only extinguished when the invoice arrives.
Some organisations achieve the same result by raising a credit note equal to the advance against the final invoice. That works, and is a common pattern in ERP-integrated environments β see what is a credit note for how that instrument behaves.
3. Tie the advance to a specific transaction
Recording the advance against the supplier is not enough. A supplier with several concurrent orders needs each advance tied to a specific reference β purchase order, contract number or project code.
Without this, applying advances becomes guesswork when multiple orders and invoices are in flight, and partial deliveries make it worse.
4. Net off automatically at invoice processing
When the commercial invoice arrives, the system should surface any outstanding advance for that supplier and reference before the invoice is approved for payment.
This is the single highest-value control. A simple rule works:
| Condition | Action |
|---|---|
| Invoice matches PO with an outstanding advance | Auto-apply advance, route balance for approval |
| Invoice value below outstanding advance | Hold β likely partial delivery, apply proportionally |
| No advance outstanding | Standard invoice flow |
| Advance exists on supplier but different reference | Flag for review before payment |
| Invoice approved with advance unapplied | Block payment |
That last rule matters most. If an advance exists against the supplier and reference, payment of the full invoice should be blocked, not merely flagged. Warnings get dismissed under time pressure.
5. Apply proper approval authority
Advances should route through the same approval matrix as invoices of equivalent value, with an additional check on counterparty risk. Paying S$200,000 in advance to a new supplier carries materially more risk than paying it in arrears against delivered goods, and the approval path should reflect that.
Reasonable additions for advances:
- New suppliers require an extra approval level regardless of value
- Advances above a threshold require verified bank details and a credit check β bank-detail change requests are a well-documented attack vector, as the ACFE reports on payment fraud make clear
- Advances above a percentage of contract value require justification
- Repeat advances to a supplier with existing unrecovered advances are blocked
6. Age the prepayment account
Run an ageing report on supplier advances the way you would on receivables. Any advance outstanding beyond the expected delivery window should be escalated to the budget holder.
A practical schedule:
| Age | Action |
|---|---|
| Under 30 days | Normal |
| 30β60 days | Confirm expected delivery date |
| 60β90 days | Escalate to budget holder |
| Over 90 days | Review for recoverability and impairment |
| Past contract delivery date | Formal recovery process |
How Does Peakflo Handle Advance Payments?
Peakflo treats advances as a tracked asset linked to the transaction that will eventually consume them.
Advances raised against a document
Advances are created from a proforma invoice, purchase order or contract reference, so every payment carries the link needed for later netting. Proforma invoice validation checks the supporting document against agreed terms before funds are released.
Automatic application at invoice processing
When the commercial invoice arrives, outstanding advances for that supplier and reference are surfaced and applied automatically, so the approved payment is the balance rather than the full value.
Payment blocking on unapplied advances
Where an advance exists and has not been applied, payment is blocked rather than warned β closing the route by which most advance-related overpayments occur.
Approval routing that reflects advance risk
Advances route through approval workflow automation with rules specific to prepayment risk, including additional scrutiny for new suppliers and for advances above a share of contract value.
Advance ageing and recovery visibility
Outstanding advances are reported by supplier, age and reference, so unrecovered prepayments surface as an operational item rather than a year-end discovery. This feeds cash flow management, since advances represent committed cash already gone.
Multi-currency advance handling
Advances paid in foreign currency are tracked in both transaction and reporting currency, with exchange differences on application handled separately from the underlying cost.
Our Verdict: How Much Process Does This Justify?
Put full controls in place if:
- You pay deposits regularly β manufacturing, construction, project services, imports
- Individual advances are material relative to monthly payables
- You have multiple concurrent orders with the same suppliers
- You have ever discovered an unapplied advance at year-end β near-certain evidence there are others
- You operate across borders, where prepayment is standard and tax treatment varies
- Advances are currently requested by email without a supporting document
Lighter handling is reasonable if:
- Advances are rare and small β a handful a year, immaterial in value
- Suppliers invoice you for the balance rather than the full amount, which removes the duplicate risk (worth confirming rather than assuming)
- All advances are fully prepaid transactions with immediate delivery, where the window for anything to go wrong is short
Even in the lighter case, the discipline of requiring a supporting document costs nothing and preserves the option to reconcile later. The teams that get hurt are almost always those that paid on an email and had nothing to work from afterwards.
Conclusion
Advance payments are the clearest example of a routine transaction that standard accounts payable is not designed to handle. Every control assumes the invoice comes first, and when it does not, those controls simply do not engage.
The result is a category of loss that is quiet and systematic rather than dramatic: deposits paid and forgotten, final invoices paid in full despite prior part-payment, prepayment accounts holding balances nobody has reviewed in years, and tax stranded because the supporting document could never support a reclaim.
None of it requires sophisticated technology to fix. Require a document. Record the advance as an asset against a specific reference. Block payment of any invoice with an unapplied advance. Age the prepayment account like a receivable.
The last point deserves the most emphasis, because it reframes the problem correctly. An advance payment is a loan to your supplier. Most organisations would never make an unsecured loan without documentation, tracking and a repayment schedule β yet they routinely wire deposits on the strength of an email and never look at them again.
Related reading: what is a proforma invoice, what is a credit note, and preventing invoice overpayments.
Want to see advance tracking and automatic netting on your own supplier data? Request a demo.
Frequently Asked Questions
What is an advance payment to a supplier?
An advance payment to a supplier is money paid before goods are received or services performed β commonly a deposit on a large order, a mobilisation payment on a project, or full prepayment where a supplier does not extend credit. Because nothing has yet been delivered, the payment is an asset representing value owed to the buyer, not an expense.
How do you record an advance payment to a supplier?
Record it as a debit to a prepayment or supplier advance asset account and a credit to cash. It is not an expense and not a settlement of accounts payable, because no liability exists yet. When the commercial invoice arrives, the full amount is recognised as a payable and expense, and the advance is applied against it so only the remaining balance is paid.
Why do advance payments cause duplicate payments?
Suppliers typically issue the final invoice for the full contract value rather than the outstanding balance. If the deposit was recorded separately, or only as a bank line with no supplier link, nothing connects the two records. AP then processes and pays the full invoice despite part of it already being settled, and the overpayment usually surfaces months later during supplier statement reconciliation.
What is a down payment request?
A down payment request is a document type used in some ERP systems to authorise and record a payment where no supplier invoice exists. It allows the payment to be raised, approved and posted to a prepayment account without creating a payable, and holds the reference needed to net the advance against the eventual invoice. It exists specifically because standard AP flows assume an invoice precedes payment.
Can you reclaim tax on an advance payment?
It depends on jurisdiction and on the supporting document. Where the advance is supported only by a proforma invoice, tax is generally not reclaimable because no taxable supply has occurred. Some jurisdictions treat receipt of an advance as creating a tax point, obliging the supplier to issue a tax invoice for the deposit and allowing the buyer to reclaim at that stage. Confirm treatment per jurisdiction.
How should advance payments be tracked to prevent loss?
Record every advance against a specific supplier and transaction reference such as a purchase order or contract, hold it in a dedicated prepayment account, and review it on an ageing schedule. Advances outstanding beyond the expected delivery window should be escalated, because an unrecovered advance is functionally a loan to a supplier that nobody is monitoring.
What happens if a supplier never delivers after taking a deposit?
The advance becomes an impaired asset and moves into recovery. Practical steps are a formal written demand referencing the contract or proforma, escalation through the commercial relationship, and if unrecovered, provision against the balance and possible legal action. This is precisely why advances should be aged β the earlier non-delivery is identified, the better the recovery odds.
Should advance payments go through the same approval as invoices?
They should go through at least the same value thresholds, plus additional counterparty checks. Paying in advance carries more risk than paying in arrears, because you hold no delivered goods if the supplier fails. Sensible additions include an extra approval level for new suppliers, verified bank details above a threshold, and blocking further advances to suppliers with existing unrecovered ones.
How do partial deliveries affect advance application?
Where delivery is staged, the advance should be applied proportionally rather than consumed entirely against the first invoice. If a 30% deposit was paid on a contract delivered in three equal shipments, 30% of the advance should apply to each. Applying the full advance to the first invoice overstates early settlement and leaves later invoices appearing fully payable when part of the contract value is already covered.
Is an advance payment the same as a prepayment?
The terms are used largely interchangeably in accounts payable, and both describe cash paid before receipt of goods or services. In wider accounting, βprepaymentβ can also describe expenses paid in one period relating to a later one β such as annual insurance β which is a timing adjustment rather than a supplier balance. In an AP context, treat them as the same concept: an asset until the supplier delivers.