Vendor Deposits and Prepayments: How to Apply Them to the Final Invoice Without Paying Twice
You paid 30% when the order was placed. Four months later the final invoice arrives, it shows the full price, and the deposit is a single line near the bottom, or nowhere at all. If AP pays the total, the vendor holds money that is yours. This post covers how prepayments should be recorded, why they get lost, and how to apply them correctly to the invoice that closes the order.
In brief
- A deposit paid to a vendor before delivery is an asset, a prepayment or vendor advance, not an expense; it only becomes part of the cost when the final invoice is matched and the deposit applied against it.
- The most common prepayment error is paying the final invoice at its gross amount because the deposit sits in a separate account with no link to the purchase order or the invoice that should consume it.
- Final invoices show deposits in different ways: as a deduction line, as a note in the footer, as a balance due below the total, or not at all, so AP has to read the whole document, not only the total.
- A monthly aging of open vendor prepayments finds deposits that were never applied, orders that were cancelled without a refund, and deposits applied twice.
What a vendor deposit is on the books
A deposit, down payment or advance paid before anything is delivered is not an expense. Nothing has been received, so there is nothing to expense or to put in inventory. It is an asset: a prepayment, or vendor advance, that represents goods or services the vendor still owes you. The entry is a debit to the prepayment account and a credit to cash, and the purchase order number should travel with it.
When the goods arrive and the final invoice is posted, the full cost goes to expense or inventory and to accounts payable. The deposit is then applied: accounts payable is debited and the prepayment account credited for the amount already paid. What remains in payables is the balance you actually owe, and the prepayment for that order goes to zero. Two entries, linked by the order. The trouble is that months can pass between them, and the link is easy to lose.
2
entries per deposit: the payment, then its application to the final invoice
4
ways a final invoice shows a deposit, listed in this post
7
steps in the monthly routine below
Why deposits get lost before the final invoice
Prepayments are paid outside the normal invoice flow. Often the vendor sends a deposit request, a proforma invoice or just an e-mail, and treasury pays it as a one-off. Several things then go wrong.
The payment carries no order reference
If the deposit was booked to a generic advances account with only the vendor name, nothing points to it when the final invoice for a specific order comes in. With several open orders for the same vendor, even a careful clerk has to guess which deposit belongs to which invoice.
The deposit request was posted as an invoice
When a proforma is entered as a regular payable and then the final invoice is entered at its full value, the cost is booked twice. The duplicate is not an exact match on number or amount, so the checks described in duplicate invoice detection only catch it if they compare by order and vendor, not by invoice number.
Progress payments outrun the paperwork
On long jobs there may be a deposit, then one or more progress payments, then the final invoice. Vendors do not always list every payment on the final document, so the invoice deducts the first deposit and asks for a balance that ignores the rest.
Cancelled orders keep their deposits
An order cancelled after the deposit leaves an asset with nothing to apply it to. Unless someone asks for the refund or a credit, it ages quietly on the balance sheet.
Order still open
Order delivered, deposit not applied
Order cancelled, no refund yet
No order reference found
Most of a healthy balance belongs to orders that are still open. The highlighted bucket is the one that costs money: orders already delivered and invoiced, whose deposits were never applied because the final invoice was paid in full.
How final invoices show deposits
There is no standard layout for a deposit on a final invoice, which is why reading only the total is risky. In practice you will see four patterns:
- A deduction line inside the line items, with a negative amount, so the invoice total is already net of the deposit.
- A block below the total, listing deposits received and a separate balance due. The invoice total is gross; the amount to pay is the balance.
- A note in the footer or remarks, such as "less deposit paid July 3", with the amount written in text and no arithmetic on the page.
- Nothing at all. The vendor invoices the full value and expects you to deduct the deposit yourself, or has simply forgotten it.
Each pattern needs a different posting. If the deposit is a line inside the total, posting the total as the cost understates it, and the prepayment stays open. If it sits below the total, posting the balance due as the cost does the same thing. The invoice total, the deposits listed and the balance due have to be read as three separate fields.
Matching the final invoice to what you paid
The check is simple once the fields exist: compare the deposits the invoice lists with the prepayments open for the same purchase order in your ledger. Define the fields once in your extraction schema: invoice type, PO number, lines, freight, tax, invoice total, each deposit applied with its reference and amount, and the balance due.
{ "invoice": { "vendor_name": "Example Fabrication Co.", "invoice_number": "F-20931", "invoice_type": "final", "invoice_date": "2026-10-12", "po_number": "PO-55810", "currency": "USD", "lines": [ { "description": "Steel mezzanine platform, installed", "quantity": 1, "unit_price": 48000.00, "amount": 48000.00 }, { "description": "Additional handrail section", "quantity": 2, "unit_price": 650.00, "amount": 1300.00 } ], "freight": 900.00, "sales_tax": 0.00, "invoice_total": 50200.00, "deposits_applied": [ { "reference": "D-20417", "date": "2026-07-03", "amount": 14400.00 } ], "balance_due": 35800.00 }, "ledger": { "prepayments_open_for_po": [ { "payment": "PAY-8812", "date": "2026-07-08", "amount": 14400.00 }, { "payment": "PAY-9140", "date": "2026-09-02", "amount": 9600.00 } ] }, "result": { "deposit_on_invoice_matches_payment": "PAY-8812", "progress_payment_not_shown_on_invoice": 9600.00, "correct_amount_to_pay": 26200.00 }}In this example the order was for 48,000.00, plus two extra handrail sections and freight, for a final total of 50,200.00. The vendor deducts the 14,400.00 deposit and asks for 35,800.00. The ledger, though, holds two prepayments on the order: the deposit and a 9,600.00 progress payment made in September that the invoice does not mention. The amount to pay is 26,200.00. Paying the balance due as printed would hand the vendor 9,600.00 that then has to be chased back, usually through a statement dispute months later.
Apply by order, not by vendor
Differences between the final invoice and the original order, such as the extra handrail and the freight, are a separate question. Check them against the order and the receipt the same way you would any three-way match exception, and only then apply the deposits to the approved amount.
A monthly prepayment routine
- Record every deposit and progress payment against a purchase order number, never to a vendor alone.
- Keep deposit requests and proformas out of the payables ledger; pay them as prepayments.
- Extract final invoices with invoice total, every deposit listed and the balance due as separate fields.
- Before paying a final invoice, compare its deposits with all prepayments open on the same order.
- Post the full cost, then apply each prepayment; pay only the difference.
- Age open prepayments monthly by status: order open, delivered, cancelled, no reference.
- Request a refund or credit memo for every deposit on a cancelled order.
The aging feeds two other checks. A credit issued for a cancelled order is matched like any other in credit memo matching, and a deposit the vendor never recorded will show up as a difference on the next vendor statement.
Where extraction fits
Applying deposits is mostly a reading problem: finding the order number, telling the invoice total from the balance due, and spotting a deposit written in a footer. Done by hand, it is done on the number at the bottom of the page. Parser extracts each invoice into structured JSON against the fields you define in a template, including the PO number, the lines, every deposit listed and the balance due, through upload, e-mail or the API. Your ERP or payment workflow can then compare those deposits with the prepayments open on the order before anything is paid.