A buyer orders a machine for €50,000 plus VAT, and the supplier wants 30% before it starts building. The supplier sends a prepayment invoice, the buyer pays it, and four months later a final invoice arrives. Accounts payable now holds two invoices with the same supplier and the same order number, and only one machine.
Nothing about the second invoice has to look wrong. Its arithmetic can be perfect, its total can match the purchase order, and it can still ask for money the buyer already paid. The mistake only shows when the two documents are read together.
This piece follows that fictional order through both invoices: what each document is, how the deposit should come off once, the tax on that deposit, and the layouts that make the word “total” unreliable. Tax rules vary by country, so the examples point at specific texts. Applying them to a real invoice is a job for your tax team.
Three documents that look alike
The UN/CEFACT code list used for electronic invoices has a code for this document. Code 386, as published by Peppol, is “an invoice to pay amounts for goods and services in advance; these amounts will be subtracted from the final invoice.” The subtraction is part of the definition. A prepayment invoice is not finished until a later document deals with it.
It is also easy to confuse with a pro forma, which can look nearly identical on the page and may also ask for money before delivery. The difference is what each one can support.
| Document | What it does | Tax evidence (UK example) | What accounts payable should do |
|---|---|---|---|
| Pro forma | Offers goods or services, which may or may not be supplied | Cannot support an input tax claim when used this way, even with every VAT invoice detail on it | Treat it as an offer. If it gets paid, expect a real invoice |
| Prepayment invoice | Bills an advance before delivery | A proper VAT invoice can support a claim, subject to the usual conditions | Record the advance and keep it open against the order |
| Final invoice | Bills the supply and settles what was advanced | A proper VAT invoice, with the tax already invoiced dealt with | Apply the advance and pay what remains |
The UK wording comes from HMRC’s VAT Notice 700, section 17.3. It tells suppliers to mark such a pro forma “this is not a VAT invoice”, and says that if the supplier then supplies the goods or receives payment, it must issue a proper VAT invoice. So a pro forma that got paid leaves a gap in the file until that invoice arrives.
The word “deposit” needs reading too. Section 14.2.3 of the same notice says most deposits are advance payments, but a deposit held as security for hired goods, refunded on their safe return, creates no tax point. The same word on two documents can call for different treatment.
The deposit comes off once
Here is the order with made-up figures and a 19% rate. The deposit is 30% of the net price, invoiced with its tax. The final invoice restates the whole contract and then deducts what was invoiced in advance.
| Line | Net | VAT at 19% | Gross |
|---|---|---|---|
| Prepayment invoice PP-1001 | €15,000.00 | €2,850.00 | €17,850.00 |
| Final invoice INV-2207: full contract | €50,000.00 | €9,500.00 | €59,500.00 |
| Less PP-1001 | −€15,000.00 | −€2,850.00 | −€17,850.00 |
| Due on INV-2207 | €35,000.00 | €6,650.00 | €41,650.00 |
Two sums prove it. The cash adds up to the contract: €17,850.00 + €41,650.00 = €59,500.00. So does the tax: €2,850.00 + €6,650.00 = €9,500.00. Both have to hold, because an invoice can pass the first and still fail the second.
Tax can move with the money
The net and tax split matters because, in VAT systems, an advance can trigger tax before anything is delivered. In the UK, section 14.2.2 of Notice 700 says that if you issue a VAT invoice or receive a payment before the basic tax point, the tax point for that amount is whichever of those comes first. Germany’s § 13 UStG has a similar effect for a part payment received before the supply: the tax arises at the end of the advance return period in which the money came in.
So part of the tax may already be declared by the time the final invoice is written. Germany spells out the consequence for that invoice. § 14(5) UStG says a final invoice must deduct the part payments received before the supply and the tax on them, where invoices were issued for those part payments. And under § 14c(1), a business that shows more tax on an invoice than it owes for the supply owes the excess as well.
Those are examples, and other VAT systems have their own texts. US sales tax works on a different logic and varies by state, so this piece does not cover it. The document problem is the same anywhere, though: the buyer holds two papers that describe one purchase, and the books should record it once.
Four ways the deduction goes wrong
Each failure below can come from an invoice whose own arithmetic is fine. Using the same order, here is what the buyer ends up with.
| What happened | Paid or claimed | Should be | Difference |
|---|---|---|---|
| The final invoice has no deduction, and it is paid in full | €77,350.00 paid | €59,500.00 | €17,850.00 overpaid |
| Only the net deposit is deducted | €62,350.00 paid | €59,500.00 | €2,850.00 overpaid |
| The cash is right, but the books take the tax from both invoices | €12,350.00 VAT recorded | €9,500.00 | €2,850.00 over-recorded |
| The advance is deducted twice, on a stage invoice and again at the end | €41,650.00 paid | €59,500.00 | €17,850.00 short |
The third row is the easy one to miss. The payment run looks correct, the supplier is happy, and the error sits in the tax return. The full contract tax of €9,500.00 is printed on the final invoice in the example, and a system that reads that field as “tax on this invoice” has just counted €2,850.00 for a second time.
The fourth row hurts the supplier first, and the buyer later when the statement arrives. It tends to come from progress billing, where each stage invoice carries its own deduction and nobody keeps a running figure.
“Total” depends on the layout
Suppliers do not agree on how to show any of this, which is why reading one field called “total” fails. The same settlement can reach you in at least three shapes:
| Layout | What the invoice shows | The number labelled “total” | What to read |
|---|---|---|---|
| Full contract with deduction | €59,500.00, then a deduction line, then the balance | Could be €59,500.00 or €41,650.00 | The line labelled as payable, and the deduction line as its own record |
| Remainder only | €35,000.00 net plus €6,650.00 VAT, perhaps with a note about PP-1001 | €41,650.00 | The note. No deduction line exists, so a check for one finds nothing |
| Structured e-invoice | Total with VAT, paid amount, amount due as separate fields | €59,500.00 with VAT; €41,650.00 due | All three fields, plus whatever identifies the advance |
The structured case is the cleanest. Peppol BIS Billing 3.0 has a fatal validation rule, BR-CO-16: amount due equals total with VAT, minus paid amount, plus rounding. In UBL, cbc:PrepaidAmount holds “the sum of amounts which have been paid in advance”. Our example passes: 59,500.00 − 17,850.00 = 41,650.00.
That rule proves the invoice agrees with itself, and no more. PrepaidAmount is one sum, with no link to a payment of yours. A supplier could state any prepaid figure and still pass validation, so it needs checking against your own record of what you paid. Structured invoices still leave exceptions makes the same point about e-invoicing more broadly.
Keep a balance for each advance
The check that catches most of these failures is one record per advance, kept open against the order until it reaches zero:
| Advance | Order | Net | VAT | Applied | Still open |
|---|---|---|---|---|---|
| PP-1001, paid | PO-4471 | €15,000.00 | €2,850.00 | €0.00 | €17,850.00 |
| PP-1001 after INV-2207 | PO-4471 | €15,000.00 | €2,850.00 | €17,850.00 | €0.00 |
A second attempt to apply PP-1001 now has nothing left to apply. An advance still open after the final invoice is paid is a reason to ask where the money went. Several deposits on one order, or one deposit split across stage invoices, fit the same record.
Three neighbouring processes need to know this record exists:
- Matching — a prepayment invoice arrives before any delivery, so a three-way match has no goods receipt to find. Compare it with the payment terms on the order instead. Route it through the normal queue and it will either stall or get waved through as an exception.
- Coding — an advance is usually not yet an expense. Most charts hold it in a prepayment or advances account until the supply happens, and your controller sets the rule. Coding suggestions learned from past invoices from this supplier may point at the wrong place.
- Cancellation — the order can die with the advance still open. HMRC’s section 8.13 says VAT stays due on a part payment the supplier keeps, and that the supplier can reclaim the VAT it accounted for if it refunds the payment. Either way, the buyer’s record needs a document that closes it, such as a credit note.
Checks that run before posting
None of these checks decide a tax treatment. They find a pair of invoices that does not agree, and send it to someone who can read both.
| Check | What to compare | When they disagree |
|---|---|---|
| Type | Title, wording and type code against pro forma, prepayment and final | Route for review; do not record tax from a pro forma |
| Advance on file | The order against open advances for this supplier | Hold the final invoice if it shows no deduction and an advance is open |
| Deduction amount | Deducted net and tax against the open balance | Show both figures, and flag any partial or larger deduction |
| Cash ties out | Advances plus amount due against the contract total | Show the difference before the payment run |
| Tax ties out | Tax on all invoices, net of deductions, against tax on the contract | Route to tax before the amounts reach the return |
| Same rate | VAT rate on the advance against the rate on the final invoice | Route to tax; a change may be correct or may be an error |
| Applied once | The advance reference against earlier invoices on the order | Show the earlier invoice and ask the supplier for a correction |
Each result should land in one of three states: applied with a source, missing or conflicting. An invoice with no deduction and no advance on file is fine. An invoice with no deduction and an open advance is a question for a person, and returning a clean “total” hides that.
What extraction changes
Most of the work is reading. Somebody has to tell a pro forma from a prepayment invoice, find a deduction printed in a different place by each supplier, and notice a reference to PP-1001 in a footnote. A document AI pipeline can classify the variant, keep the net, tax and gross of a deduction as separate fields, and tie each value to the page it came from.
Cogneris recognizes prepayment invoices as one of the invoice variants it classifies, and its validator runs arithmetic checks on totals before the data reaches your ERP. Low-confidence values go to a person with the reason attached. The open balance belongs in your own system, because that is where payments are recorded, and extracted fields are what feed the comparison. Extraction does not decide what tax is due or whether an advance can be applied.
The final invoice asks for €41,650.00. If PP-1001 is on file with €17,850.00 open, and it closes to zero when you post, the deposit left the bill once and the tax was counted once.
Sources
- Invoice type code list (UNCL1001 subset) — code 386, prepayment invoice (Peppol BIS Billing 3.0, May 2026 release).
- Peppol BIS Billing 3.0 — rule BR-CO-16 and the monetary totals;
cbc:PrepaidAmountin the UBL syntax. - VAT guide (VAT Notice 700) — sections 8.13, 14.2.2, 14.2.3 and 17.3 on forfeited deposits, tax points, deposits and pro forma invoices (HMRC).
- § 13, § 14 and § 14c UStG — when tax arises on part payments, deduction on the final invoice, and overstated tax (Germany, Federal Ministry of Justice; German text, our summary).
The order, invoice numbers, rate and amounts above are invented for illustration. This article is general information about document handling, not tax or accounting advice.