Beyond Build vs Buy: What Actually Decides Global E-Invoicing

The market still frames global e-invoicing as one decision with two answers: build compliance inside your ERP, or buy it as a service from a specialist. It is a fair question, but on its own, it settles very little. That choice does not make a company’s data compliance-ready, does not prepare it for the next mandate, and does not keep its core clean through a decade of regulatory change. Those outcomes are settled on four different axes. This is what a serious approach to global compliance should look like on each of them, and why the real test of any provider is whether a company is still free to walk away.

The Binary Everyone Gets Wrong

Ask an enterprise how it plans to handle mandatory e-invoicing across its markets, and the answer usually comes back as a build-or-buy decision. One camp wants to keep everything native: extend the ERP, use its localization modules, and own the build. The other wants it done for them, handing the whole problem to a compliance-as-a-service vendor. Both are legitimate operating models. The trap is treating that choice as if it also settles the harder things underneath it.

It does not. The clearest example is data. Incomplete or poorly structured data will break a clearance flow, whether you built it inside your ERP or handed it to a specialist. The invoice is rejected the same way, and the consequences fall on the company the same way. That choice is not a data-quality strategy. It is also not a readiness strategy for the mandate that lands two years from now, nor a guarantee that a government’s shifting specification will not reach back into the core.

So the binary is necessary but not sufficient. Both paths face the same hard problems, and neither automatically wins any of them. The more useful move is to stop arguing about where the software sits and start asking what the approach has to be able to do. In practice, it comes down to four axes: how it connects to a company’s ERP landscape, how far its regulatory reach actually extends, what kind of engine sits at its core, and how it is delivered. Compliance lives or dies on all four, whatever mix of ERP systems a company happens to run.

1. ERP Integration: “Native depth. Agnostic reach.”

Start with the axis closest to the binary, because it is the one most often misread. “Native depth” does not, and should not, mean a provider reaching into the raw tables inside your ERP. Depth belongs at the integration boundary, not in the internals of your core.

It means three things. First, deep interoperability with the major ERP systems: many ways to connect to each, and the ability to map their output into whatever format a jurisdiction requires. That is earned experience, not access to your database. Second, validation of a company’s data against each jurisdiction’s rules, telling it early and clearly which fields are missing or malformed. Third, enrichment on the outgoing document, filling the gaps on the provider’s side, in the open, rather than pretending the ERP already produces a perfect invoice. Companies often discover, only when a structured format forces the issue, that they were never capturing a data point required by an incoming mandate, and that it is far cheaper to learn that from a validation report than from a rejected invoice.

The reason matters. ERP databases are normalized for day-to-day operations, not for regulatory reporting, which is why raw ERP output is rarely ready for compliance, and why trying to rebuild that regulatory meaning out of those tables is fragile and error-prone. It works better the other way round: the source data stays in a company’s own systems, and the provider checks it and completes it at the boundary. A small example makes the point. If a company wants a status file back for every invoice it sends, it should define how that file has to look, and the provider should deliver against that definition. That is already a preview of the fourth axis: configured to you.

Now the honest complication. Plenty of enterprises lack the people, the time, or the in-house skills to get their ERP data ready for a mandate, and they would happily have the provider handle the data for them, source tables included. The need is real and should not be dismissed. But separate the need from the method, because reaching into a company’s tables carries risks that outlast whatever it solves today.

• It does not compose at the next mandate. The compliance surface only grows: e-invoicing now, electronic freight documents (eFTI, eCMR) next, e-reporting after that, then payroll and other document types. Suppose a provider reached into your tables for invoicing and does not cover transport, or you chose a different provider for logistics. Now a second provider has to do the same. Repeat that across mandates and providers, and your core ends up with several separate routes reaching into it, each one more thing to secure and to re-test every time anything changes.
• It locks you in more deeply. Custom extraction logic written against your tables is one of the hardest kinds of lock-in to undo. It lives inside your core; only that one provider understands it, and unwinding it becomes a core-system project. You escaped ERP lock-in and walked straight into provider lock-in.
• It re-creates the coupling you wanted to avoid. Any change to your ERP can quietly break those routes, whether it is an upgrade, a new module, or a system inherited through an acquisition. Your teams then have to re-test the provider’s extraction every time, which is the same maintenance burden that moving compliance out of the ERP was meant to remove.
• It adds a fragile step. Rebuilding the compliant dataset out of your raw fields is extra work, and every extra step is one more place where something can go wrong, whoever is at fault. It also makes problems harder to locate: when a value is wrong, it is less clear whether the issue is in your data or in the provider’s extraction.
• It hides the real problem. If bad data is quietly patched on the way out, it never gets fixed at the source. The same defect comes back later for the next provider, for a company’s own reporting, for an auditor, or for the next mandate. A good provider surfaces these issues so a company can fix them at the source, which improves everything downstream, rather than covering them up inside the pipe.

There is a better way to help a company that lacks the resources. Validation shows what is wrong. Enrichment fills the gaps in the outgoing document, in the open. And when a company really needs more support, that support should be a clear, named service, not something buried inside the flow that the company can neither see nor take back.

This gives the axis a simple test, call it the removability test. A good provider makes itself removable. Ask one question: if a company switched providers tomorrow, how much of its own core would it have to rebuild? Checking and completing data at a clean boundary means almost nothing needs rebuilding, because the ERP was never touched. Reaching into the tables means a great deal. Real partnership is built so that a client could leave, and that is what earns trust across a decade of expanding mandates.

“Agnostic reach” is the easier half and needs little defense: any-to-any across the many ERP systems a large group actually runs, so that a fragmented landscape is brought onto a single integration instead of a patchwork of local point solutions.

2. Regulatory Reach: “Local by law. Global by design.”

Reach is the axis most people read too narrowly. The shallow version counts flags on a map: how many countries are covered today. But a mandate map is a snapshot of a moving target, and coverage is not one-dimensional. Real reach runs along at least four dimensions at once.

• Geographic. The jurisdictions with live mandates (Germany, France, Poland, Italy, Oman, Saudi Arabia, Thailand, Malaysia, and a fast-lengthening list), and the ability to keep exchanging documents everywhere there is no mandate at all.
• By document and channel. E-invoicing where a country mandates it, e-invoicing on a voluntary basis where it simply makes operations run better, and EDI for the wider set of commercial and transport documents such as orders and dispatch advices. Reach is the whole span of documents a company exchanges, not only the tax invoice, which is where a pure tax vendor falls short.
• By regulatory regime. Post-audit, clearance, and CTC, Peppol-style four- and five-corner models, e-reporting, and prefilled returns. The same country moves between these over time.
• In time. Cross-border reporting under ViDA and the electronic freight documents arriving with eFTI are not a someday concern. Credible providers are already building them and, in some cases, delivering them. Reach that looks ahead means the provider is already where a company will be required to be.

Put those together, and the tagline becomes concrete. “Local by law” means getting every single point right, matching each administration’s specific rules. “Global by design” means breadth across the whole, one relationship that already anticipates the next country, the next document type, and the next regime. This is the same idea as the first axis, one level down: depth without reach is a strong connection to a single place, while reach without depth means being present in many places without doing much to help a company run its document flows. Coverage on its own is not enough. A good provider does more than connect. It enhances the flow with the capabilities that let a company automate its document exchange smoothly, whatever each local market requires.

The client value is easy to state once you look past the first integration. The real cost of compliance is never the first country you connect to. It is the Nth change: a new jurisdiction, a new document, a regime that shifts under you. Reaching across all four dimensions drives the cost of that Nth change on the company’s side toward zero. There is no renegotiating the relationship, no re-scoping a project, no onboarding another vendor every time the map moves. The invoice is only the anchor for a wider move toward connected digital trade, where tax, logistics, and financing increasingly travel together, and reach, understood this way, keeps a company ahead of that move instead of chasing it.

All of this variety and constant change has to be handled somewhere, and there are broadly two ways to do it. One is to write custom code country by country and connect systems point to point, which is fragile and tends to break just when a new requirement lands. The other is to run everything through one shared engine. What that engine is and how it behaves is the next question.

3. Platform Engine: “A Core That Never Guesses. AI Everywhere It Helps.”

So what should that engine look like? The instinct to put AI everywhere is the wrong one. AI needs clean data, and compliance data has to be clean because it is legally binding, which is a reason to keep the binding path strictly rule-based, not a reason to let an AI model make those decisions. An engine that invents a rule before an invoice reaches a tax authority or a trading partner is not saving anyone time. It is producing non-compliance at scale.

The core has to be completely deterministic: what is sent, from whom, to whom, and how it is delivered, together with the format translation, the enrichment, and the acceptance and approval steps in between. Nothing on that binding path should ever be left to chance.

Around that core, a provider should take full advantage of what agentic AI now offers. It can carry the heavy mapping work, speed up the R&D that keeps pace with changing formats, and support day-to-day operations. Two rules hold everywhere. Anything a customer depends on must never be left to guesswork, and a person stays in the loop at every stage, whether the task is R&D or a live production invoice. The payoff is speed and quality: a new country brought online sooner, a change absorbed faster, and fewer errors reaching production.

This is also what keeps the reach from the previous axis affordable over the long run. AI brings down the cost of each new mandate and each new mapping, while the deterministic core keeps the binding part safe. The rule a buyer should follow is straightforward: the core stays deterministic on binding flows, and AI is used where it speeds things up and lifts quality, never where it makes the binding decision.

4. Delivery Model: ”Configured to You. As Standard as You’d Want.”

The fourth axis comes back to the choice the article started with, because the real decision was never native versus service. It was the two extremes hiding inside that framing. At one end sits a rigid, out-of-the-box SaaS that forces a company’s operating model to bend to the tool. At the other sits a code a company builds and maintains itself, and with it the full cost of ownership: the build, the specialist level-two and level-three support a normal helpdesk cannot provide, and the constant maintenance. Neither extreme is the answer. The answer sits between them: configuration on a shared engine. A company gets the advanced rules its systems need and a proper fit with the wider IT landscape, without custom code and without the fragility of point-to-point links.

“As standard as you’d want” is not a polite word for flattening local reality. It means better visibility across global flows while still delivering the local behavior each market demands. The specifics differ sharply by country: France’s advanced invoice lifecycle, Poland’s particular self-billing rules, Germany’s multi-channel and multi-format reality where the core duty is to meet the CEN standard, Italy’s constant changes in processing and archiving, Saudi Arabia’s phased clearance with its QR-code and stamping requirements, India’s link between invoice registration and the e-way bill that lets goods move, and Mexico’s PAC-cleared model with its document complementos (supplements). Global coherence and local precision are not opposites, and a mature delivery model provides both.

This is where buyers should get demanding, and increasingly they do, pressing vendors for real evidence of a “glocal” capability, of interoperability that actually works, and of coverage across the wider scope of digital trade rather than the invoice alone. A few principles are worth holding any provider to.

• One in-house platform, one integration. The right model consolidates fragmented local solutions through a single ERP integration, with coordinated multi-country rollouts, and owns its own stack rather than stitching coverage together through subcontractors.
• Real legal and compliance depth. A buyer should expect an in-house legal team that tracks mandates worldwide, engages regulators directly, and helps shape the standards themselves through bodies such as Peppol, EESPA, and DBNAlliance, alongside transparent pricing. When companies name this kind of depth and clear pricing as the main reason they chose a provider, that tells you what the market values.
• Proven delivery at scale. A mature provider should be able to launch several national mandates at the same time, for hundreds of companies, without a drop in performance, and handle the first-day surge of a major clearance mandate without buckling. Reliability at that scale is a baseline expectation, not a bonus.

Honesty about limits belongs to the same discipline, because it is what separates creating a category from selling into it. A buyer should expect proactivity as well as responsiveness: initiative in scheduling, direction, and legal advice. They should also ask, plainly, which regions a provider serves natively and which it serves through partners. Coverage that leans European, with several LATAM and APAC markets delivered through partners and narrower B2C than B2B/B2G support, is a reasonable model, provided it is transparent, and the native strength in the core regions is deep rather than thin-but-everywhere. Additionally, a buyer preparing for e-reporting should judge providers by their direction of travel toward a single dashboard spanning every country. Unified cross-country visibility is the next frontier, and it matters most for ViDA readiness, so it is better judged as a trajectory than as a finished feature.

The Real Decision

Step back, and the choice looks different. It was never about which module, and not really about build versus buy. It is about who owns the layer that turns a company’s data into compliance, and whether that layer turns the data a government now demands into an advantage rather than a cost. The four axes are how you judge it. Depth without reach leaves a company accurate in one place but stuck. Reach without depth leaves it present everywhere and sure of nothing. A clever engine that guesses on the binding path is a liability. And any of it becomes a trap the moment the provider is no longer removable.

That last point is the one to keep. The healthiest sign of a compliance partnership is that a company stays free to leave it. A provider confident enough to remain removable is one built for a decade of expanding mandates, not one relying on a client’s inability to walk away. That is what native depth, agnostic reach comes down to: getting the local detail right, covering the whole span a company needs, keeping the binding core rule-based, and staying easy to leave.

Mateusz Czarnecki

Head of Product Management for Comarch EDI / E-Invoicing