When an Employee’s Receipt and a Certified Platform Send You the Same Invoice Twice

Most e-invoicing guidance assumes a clean line: a supplier issues an invoice, it arrives through a certified platform, it becomes a purchase draft. Expense reports do not follow that line. An employee buys something, photographs the receipt, and submits it through the expense process — while the same supplier, separately, may also file the invoice with a certified platform because the reform requires it. Business Central can end up looking at the same purchase from two directions at once, and reception logic built only for the standard case gets this wrong in specific, findable ways.

Why does an expense report complicate e-invoicing reception at all?

A standard purchase invoice has one path: supplier to platform to purchase draft to posting. An expense-report purchase has two candidate paths that both describe the same real-world transaction — the employee’s submitted receipt, and the certified platform’s e-document — and the system has to resolve them to one posting, not two. Neither path is wrong on its own; the employee did submit a real receipt, and the supplier did meet a real obligation to file with a platform. The mistake only appears once both paths are treated as if they were unrelated. We cover the standard reception path in detail elsewhere; this is what changes when the purchase started with an employee, not a purchase order.

What is the first thing that breaks if you reuse standard purchase-invoice logic here?

The amount. A standard purchase invoice line splits the net amount and VAT, because the entity will typically recover that VAT separately. An expense-report journal line is usually posted at the gross amount the employee actually paid — there is no separate net/VAT split happening in the same place. We found this the direct way: reception logic that extracted the net amount from an e-document, correct for a standard invoice, posted the wrong figure once the same document represented an employee’s expense claim. The document was read correctly. The amount treatment it fed into was built for the other case.

What about the document itself — does it attach cleanly?

Not by default. We found an e-document’s supporting PDF attaching itself more than once to the same record — a small bug on its own, but one that matters more here than on a standard invoice, because an expense claim is exactly the kind of document someone reopens later, during an audit or a dispute about what was actually claimed. A duplicate attachment does not change what was posted, but it does make anyone checking the record trust it less.

Does the connector need to track more than the invoice itself?

Yes — the relationship between the e-document and whatever it eventually becomes. We built this as a strict one-to-one link, and for a reason that is easy to miss: without it, nothing stops the same e-document from being processed into more than one journal entry if a user reopens the draft, or from an intermediate document staying visible after the real posting exists, leaving two records that look like they might both be live when only one is. The traceability needs to run both directions — from the journal entry back to the source e-document, and from the e-document forward to wherever it was actually posted — because an auditor or a finance lead checking the record later starts from either end, not always the same one.

What does this look like for one purchase, start to finish?

An employee books a hotel for a client visit and pays on a personal card. They photograph the receipt and submit it through the expense process the same evening. Separately, because the hotel is required to file through a certified platform, the same invoice arrives days later as a formal e-document addressed to your entity. Nothing about either event is wrong — both are exactly what each process is supposed to do.

What has to happen next is resolution, not duplication. The system needs to recognise that the incoming e-document corresponds to a purchase already claimed through the expense process, not a new, unrelated invoice to post on top of it. Get that wrong and the purchase is posted twice — once through the expense report at the gross amount the employee paid, once through the standard reception path at a net amount that assumes VAT recovery that was never actually going to happen for this claim. Finance ends up reconciling a discrepancy that should never have existed, weeks after the trip, with no obvious link between the two records pointing them back to each other.

Does the finalisation step need to know which path it is on?

It has to ask, not assume. We built a dialogue at draft finalisation that resolves which path a document is on — a standard purchase invoice, or an expense claim that should post to the employee’s record — because guessing wrong at that point is expensive to unwind afterward: two documents, two amount treatments, and only one of them correct for a given claim. Automating that choice away entirely was tempting and, in our testing, wrong more often than it was right: a supplier name or a document format is not a reliable signal for which path a given purchase should take, and a wrong automated guess is harder to catch than a question a human answers once at finalisation.

The Asio Services way

We did not design FacturaLink’s reception logic assuming every document is a standard purchase invoice, because in the groups we work with, it never is. Expense claims, advance payments, group purchases — every deviation from the simple case is where a connector’s actual design shows, not the demo. Start with our clarity form and tell us where your entities’ purchasing actually deviates from the standard case; that is usually where the real risk sits.

FAQ

Can the same purchase legally arrive as both an expense receipt and a certified-platform e-document?

Yes — the supplier’s obligation to file through a certified platform is independent of how the buyer’s employee happened to pay and claim it. Business Central has to reconcile the two records to one posting, not assume only one will ever arrive.

Is the VAT treatment always different between a purchase invoice and an expense claim?

The pattern we found is that expense-report journal lines are typically posted gross, where a standard purchase invoice line splits net and VAT — but the specific treatment depends on your entity’s setup, and it is exactly the kind of detail worth confirming before reception logic is built around an assumption.

Does the duplicate-attachment issue affect what gets posted?

No, it does not change the posted amount or status — it affects whether the supporting record looks trustworthy when someone reopens it later, which matters more for an expense claim likely to be checked than for a routine invoice.

Who should decide whether an incoming e-document is a purchase invoice or an expense claim?

The system should ask at finalisation rather than infer it silently, because the two paths have different amount treatment and different postings — getting it wrong is a correction, not a preference.