Advance Payment Invoices Are Where Most E-Invoicing Connectors Quietly Break

A standard purchase invoice — one supplier, one delivery, one document — is the easy majority of what a certified platform sends you. Advance payments are not: an advance invoice, sometimes a matching credit note when it is reversed, and a final invoice that has to reconcile against both. We found, building FacturaLink’s reception logic, that this sequence is where a connector’s real design shows.

Why do advance payments need special handling at all?

An advance payment invoice and its matching credit note carry a distinct document type in the AFNOR document taxonomy, separate from a standard invoice or credit note. That is the theory. In practice, the transport format does not always preserve the distinction cleanly: we found an incoming advance-payment credit note arriving over UBL tagged as a generic credit note type, not the specific prepayment type the taxonomy defines. A connector that trusts the transport format’s type field at face value will misclassify the document — and a misclassified advance-payment credit note does not behave like a misclassified anything else, because everything downstream (the purchase draft it should create, the invoice it should later reconcile against) depends on getting that classification right first.

What does Business Central actually need to create from an advance-payment e-document?

Two distinct purchase documents, not one. The advance invoice itself needs a purchase draft that posts as a prepayment, not a standard invoice — the accounting treatment differs, and getting that wrong is a chart-of-accounts problem discovered at close, not at reception. Later, when the final invoice for the same order arrives, it has to be created and linked so it nets correctly against the advance already posted, rather than treated as an unrelated new invoice that happens to reference the same purchase order.

What is the most common mistake once both documents exist?

Giving the final invoice the same supplier invoice number as the advance payment. It sounds like a minor bookkeeping choice; it is not. Business Central treats the supplier invoice number as a duplicate check, and if the final invoice inherits the advance’s number instead of carrying its own, the system flags it as a duplicate of a document you already posted — and blocks it. The fix is not clever reconciliation logic. It is making sure, at the point each e-document is created, that an advance invoice and the final invoice that follows it are never allowed to share that field, because the reform’s document flow assumes they are two separate postings from day one.

Does the AFNOR status lifecycle work the same way for an advance invoice?

It has to, and this is where it is easy to build something that looks finished but is not. We found a case where validating a purchase draft created from an advance-payment e-document posted the invoice correctly in Business Central but left the AFNOR status on the underlying e-document at Déposée — the outgoing Approuvée status never got sent, because the status-update logic had been written and tested against the standard invoice path, not the prepayment one. The purchase draft looked done. The document, as far as the certified platform and your supplier could see, still looked untouched. We cover what each AFNOR status actually signals in more depth elsewhere — the point here is narrower: every distinct document type your connector creates needs its own path to that status update, not a shared one that only some documents actually reach.

What does this look like for a real order?

Take a manufacturer billing a custom order in two stages: 30% on order confirmation, the balance on delivery. The advance invoice arrives as an e-document and has to post as a prepayment against the purchase order — not as a standalone invoice, or the order’s remaining balance will be wrong from the start. Months later, the delivery invoice arrives for the full order value. Business Central needs to recognise that this document nets against the prepayment already posted, applying the 30% already paid rather than billing the full amount again. If the connector treated the advance as a generic invoice instead of a prepayment, this step is where the mismatch surfaces — usually as a balance that does not reconcile, discovered by someone in accounting, not by the system flagging it at the point the second document arrived.

The AFNOR status lifecycle has to run correctly on both documents independently. An advance invoice that posts cleanly but never sends its outgoing status leaves your supplier’s platform showing an unresolved document for a transaction your own books consider closed — the exact discrepancy an auditor, or a supplier’s collections team, eventually asks about.

Why does this matter more for the industries that use advance payments heavily?

Manufacturing to order, construction, and any supplier relationship with milestone billing run a meaningful share of their purchase volume through advance payments and staged invoicing, not standard single-shot invoices. For those groups, “the connector handles standard invoices well” is not the same claim as “the connector handles our invoicing,” and the gap between the two only shows up once real volume runs through it — not during a demo built on the easy case.

What should a group ask before trusting a connector with this?

Ask for the advance-payment and credit-note path specifically, not a general demo. Ask what happens to the AFNOR status on a prepayment document at each step, not just on a standard invoice. And ask how supplier invoice numbering is kept distinct between an advance invoice and the final invoice that follows it — if nobody can answer that last one directly, the gap described above has probably not been found yet, because it only surfaces once a real advance-and-final pair runs through the system.

The Asio Services way

We did not design FacturaLink’s document handling against a spec sheet. We designed it against the cases that actually broke when we built it — advance payments among them — and kept the fixes in the connector rather than as workarounds bolted on afterward. If your entities run meaningful volume through advance payments or staged billing, that is exactly the kind of detail worth surfacing before the reform, not after. Start with our clarity form and bring the case that actually matters to you.

FAQ

Do all certified platforms transmit advance-payment documents the same way?

Not reliably at the transport-format level. The document taxonomy defines a distinct type, but we have seen a real case of an advance-payment credit note arriving tagged as a generic credit note instead. A connector needs to classify from more than the stated type field.

Can Business Central post an advance invoice and its final invoice as one document?

No, and it should not try to. They are two distinct postings with different accounting treatment — the advance as a prepayment, the final invoice reconciling against it. Forcing them into one document is what causes the duplicate-number problem described above.

Does refusing a document work differently for an advance-payment invoice?

The mechanism is the same — a purchase draft, a reason code, an outgoing status — but the status-update logic has to be built to reach every document type your connector creates, including prepayment documents, not only standard invoices.

Is this relevant if we barely use advance payments today?

Less urgently, but the reform does not make an exception for occasional use. The one advance-payment invoice a quarter is exactly the kind of document that gets stuck if nobody tested that specific path, because the standard invoice volume never exposes the gap.