Business Central E-Documents Testing and E-Invoicing Compliance

For most of the last decade, e-invoicing was somebody else’s problem, an Italian requirement, a public-sector thing, a project for next year. That has changed, and for a lot of Business Central customers it changed while they were not really watching.

France’s obligation for every VAT-liable business to be able to receive structured e-invoices took effect on 1 September 2026, with issuance for smaller companies following in September 2027. Belgium’s B2B mandate went live in January 2026 and Poland’s KSeF rollout completed in April. Germany has required reception since January 2025, with issuance phasing in from 2027. Greece adds small and medium companies to its B2B mandate on 1 October 2026.

Business Central e-invoicing runs through the E-Document framework, and for the small and mid-sized businesses BC serves, that framework is the whole compliance mechanism. It is also, in most implementations, configured once by a partner during a project and never tested again.

Which is a problem, because e-invoicing fails differently from everything else in your system, and the way it fails is quiet.

The Compliance Calendar Is No Longer Hypothetical

A rough picture of where things stand. Dates move, exemptions vary and this is not tax advice, so confirm your own position with an adviser, but the direction is not in doubt.

Two things follow from that table. If you trade into more than one of these markets, you are not implementing e-invoicing, you are implementing several different regimes with different formats, different validation rules and different failure behaviour. And if you are a UK, US or non-EU business selling into the EU, your customers’ obligations become your problem the moment they require a structured invoice you cannot produce.

Why E-Invoicing Testing Is a Different Discipline

Testing an e-invoice is not like testing anything else in Business Central, for one structural reason.

The counterparty is a tax authority, and the failure is not yours to fix.

When a posting routine misbehaves, you find out, you diagnose it, you correct it. The loop is inside your building. E-invoicing inverts all three:

• Validation happens outside your system, against a schema you do not control, maintained by a government platform or a Peppol access point that updates on its own schedule.
• Failure is financial before it is technical. A rejected invoice is not a defect in a backlog, it is an unpaid receivable, and in a clearance country it may be an invoice that legally does not exist.
• The feedback is slow and frequently opaque. A schema violation comes back as a code, sometimes days later, sometimes only as a document that never arrived. Nobody rings you.

There is a fourth difference that makes the first three worse. Most of the e-document setup looks like configuration rather than code, field mappings, service definitions, workflow steps, and configuration tends to escape testing entirely. It was set up during the project, it worked in the demo, and nobody has asked since.

“Sent” Does Not Mean “Accepted”

Business Central tracks an e-document through a status progression, created, exported, sent, and in clearance countries, cleared. Those statuses are useful, and they are also the most commonly misread thing in the whole framework.

The distinction matters enormously. In a Peppol country, a successful send means your access point accepted the transmission, the receiving end may still reject it on a business rule your document violated. In a clearance country such as Italy or Spain, where the e-document service is flagged as a clearance service, the authority’s approval is the event that makes the invoice real, and it arrives back as an identifier you are expected to carry on the document.

So a test that asserts the status reached Sent has verified that your outbox worked. It has not verified compliance. This is the same distinction that separates checking a success message from checking a ledger entry, and here the gap between the two has a statutory consequence attached.

Five Ways BC E-Document Compliance Quietly Breaks

1. The document sending profile routes you down the legacy path

To use the E-Document framework, the Document Sending Profile must have Electronic Document set to Extended E-Document Service Flow with a workflow attached. Microsoft’s documentation is explicit that Printer, Email and Disk should be set to No, because enabling them activates the older e-invoicing path instead.

This is the most dangerous configuration error in the framework, precisely because nothing looks wrong. Documents are produced, emails go out, users see activity. You are simply not using the compliance mechanism you believe you are using. A test that checks a document was emailed will pass happily while you are out of scope of your own mandate.

2. Master data gaps that only surface at validation

Structured formats demand fields that a PDF never needed. A customer’s VAT registration number, their Peppol participant identifier, country and currency codes in the right form, unit-of-measure codes that map to the standard list, a valid legal entity identifier on your own company.

Each of these is fine until the one customer with a blank field posts an invoice, and the failure is per-record rather than systemic, so it survives any test that uses a single well-formed customer. Compliance breaks on your worst data, not your best.

3. Mapping and schema drift

The framework carries export and import mapping setup to translate BC values into the format’s expected codes. Those mappings are static. The schemas they target are not, authorities revise validation rules, Peppol publishes new BIS versions, and a code that validated last quarter can be rejected this one, with no change on your side at all.

This is a API contract testing problem in a compliance costume, and it behaves exactly like one: the integration is unchanged, the counterparty’s expectations moved, and you find out through a rejection.

4. Multi-country routing sending the document to the wrong service

An organisation trading in several regimes runs several e-document services, Peppol for Belgium, a clearance service for Italy, a localisation for Germany, each with its own workflow. The routing decision depends on configuration and customer data.

When that decision goes wrong the document is still produced and still sent, just through the wrong regime. It is technically successful and substantively non-compliant, and it is close to invisible without testing the country matrix deliberately.

5. Retention policies quietly disposing of your evidence

The framework keeps an e-document log, an integration log, a mapping log and the underlying data storage, each governed by a retention policy. Those logs are the record of what you transmitted and what came back, which is precisely the evidence an audit will ask for (testing checklist for ERP compliance).

A retention policy set for storage economy rather than statutory requirement will delete it on schedule, without complaint. This is worth checking once, deliberately, against the retention period your jurisdiction actually demands.

Inbound Is Where the Money Quietly Goes

Almost all attention on e-invoicing goes to outbound, will my invoice be accepted. The larger financial exposure is on the way in.

Business Central’s inbound framework can import received e-documents automatically and create purchase documents from them without anyone looking. The service configuration includes automatic import on a timed batch, automatic processing into purchase documents, and a set of lookups that resolve the supplier’s data into yours: item reference and GTIN lookups to identify what was bought, account mapping to decide which general ledger account an incoming text belongs to, unit-of-measure resolution, line discount validation and totals verification.

Every one of those is a decision. Made automatically. On a supplier invoice.

An item reference that resolves to the wrong item, or an account mapping that picks the wrong GL account, produces a perfectly valid purchase document that is wrong, and posts it at volume, unattended, for as long as nobody notices.

The failure mode here is not a rejection. It is a clean, plausible, incorrect entry in your accounts, repeated. And because the process was designed to run without supervision, the thing that would normally catch it, a person looking at the document, has been deliberately removed.

There is now a further wrinkle. Microsoft has added Copilot assistance to e-document matching, which means a non-deterministic component sits inside an accounting path. That is not an argument against using it; the matching problem is genuinely well suited to it. It is an argument for validating it the way you would validate any agent making decisions in a financial process, checking the decision, not just the throughput, and knowing where a human still belongs in the loop.

What to Validate

A workable set, organised by where the risk sits rather than by feature.

That last row is worth dwelling on. Plenty of BC implementations handle rejections technically, the status stops, the log records it, without anybody being told. An e-invoice that failed three weeks ago and nobody noticed is functionally an invoice you never sent, and you will discover it when the customer does not pay.

Three Clocks, None of Them Yours

The reason e-document compliance cannot be validated once at go-live is that three independent schedules act on it.

1. Business Central updates monthly, with two major releases a year, and the e-document framework and its localisations move with them. The French localisation arrived in a 2026 release; more will follow as mandates land.

2. Your connector or access point updates on its own schedule, as an AppSource app maintained by somebody else entirely.

3. The authority changes the rules, new schema versions, tightened validation, additional mandatory fields, on a timeline driven by legislation rather than by software.

Any one of those can invalidate a configuration that has worked for a year, and none of them will ask your permission. Which makes this a standing check rather than a project task, and one that has to be cheap enough to run every month, or it will not be run at all.

How Sofy Validates BC E-Invoicing

Sofy’s Dynamics 365 test agents role here is to check the things that only reveal themselves in the payload and the posting, and to do it often enough to catch drift.

Validation targets the content, not the status. The assertion is that the generated document carries the right VAT treatment, the right party identifiers and totals that reconcile to the posted invoice, not that a status field reached Sent. That is the difference between testing compliance and testing your outbox.

The country matrix runs unattended. One scenario per regime, per document type, exercised on a schedule rather than when somebody remembers. Checking four regimes by hand is a day nobody has; checking them overnight is a cost nobody notices.

Inbound decisions are checked, not just counted. Whether the item reference resolved to the correct item and the account mapping selected the correct GL account, including the ambiguous cases that a happy-path test will never generate.

Configuration drift is caught as a test, not a memory. That the sending profile still routes through the E-Document framework, and that retention policies still meet the statutory period, are assertions that can run every month tests that survive monthly change, rather than facts somebody is assumed to remember from the implementation project.

What this does not replace

Your access point or service provider still handles transmission, and their validation is a genuine layer of protection, this complements it rather than duplicating it. Tax advice remains tax advice: no test can tell you whether you are in scope of a mandate, and that determination belongs with an adviser. And the decision about which regimes to support is a commercial one. What automated validation removes is the assumption that a configuration set up eighteen months ago still does what everyone believes it does.

Frequently Asked Questions

How does Business Central handle e-invoicing?

Through the E-Document framework, which requires the E-Document Core app. You configure an e-document service defining the format, Peppol BIS 3.0 or a localised format such as XRechnung, ZUGFeRD or Factura-E, attach a workflow that exports and sends, and point the document sending profile at it. Clearance countries additionally flag the service so the tax authority’s approval is part of the flow.

What does it mean if an e-document status is Sent?

Only that Business Central handed the document to the configured service. It does not mean the tax authority validated it, the network delivered it, or the recipient can process it. In clearance countries the meaningful status is Cleared, which reflects an actual approval and returns an identifier. Testing that a status reached Sent verifies your outbox, not your compliance.

Do I need to test e-invoicing if my partner set it up?

Yes, and more so than most other configuration. It was set up correctly for the regimes, formats and data that existed on that day. Business Central updates monthly, connectors update independently, authorities revise schemas on legislative timelines, and your customer data changes constantly. None of those will notify you when your configuration stops being adequate.

What is the difference between Peppol and a clearance country?

In a Peppol model the document travels through a network of access points directly to the recipient, and validation is against the format’s rules. In a clearance model, Italy, Spain, and others, the document goes to the tax authority first, which approves it and returns an identifier before it reaches the customer. Business Central supports both, but they have different flows and different definitions of success, so they need separate test coverage.

What should BC e-document testing actually check?

Payload content against the target schema, correct routing per country, real acceptance rather than dispatch, inbound matching resolving to the right items and accounts, master data completeness before posting, and that rejections reach a person. The single highest-value check is inbound: it runs unattended, posts to the ledger, and fails silently.

How often should we run e-invoicing compliance tests?

Monthly at minimum, aligned to the Business Central update cadence, plus on any connector update or announced schema change. The three schedules acting on this, BC, your connector and the authority, are independent, so any of them can break a working configuration between checks. The practical constraint is cost: the check has to be cheap enough that it happens without anyone deciding to do it.

The Bottom Line

E-invoicing has stopped being a future compliance project for Business Central customers. France’s reception obligation is live, Belgium and Poland are live, Greece expands this week, Germany’s issuance phase begins in 2027, and ViDA makes structured invoicing the intra-EU default by 2030. If you sell into Europe, you are either in scope now or you will be shortly.

The E-Document framework is a capable answer to that, and for most SMBs it is the entire answer. But it is configuration, set up once, rarely revisited, acted on by three schedules nobody controls, and its most useful-looking status tells you about your outbox rather than about your compliance.

The question worth asking is not whether e-invoicing is configured. It is when anyone last confirmed that what leaves the building is correct, that what arrives is posted to the right place, and that a rejection would reach a human being before a customer noticed the invoice never came.