This deep dive expands on the Loop Asia conversation with Fethi Rabhi, Professor of Software Engineering at UNSW, and Alan Hsiao, founder and CEO of Cognitivo.

Fethi Rabhi mentioned France's e-invoicing reform almost in passing. It previews a pattern that will hit every technology leader running cross-border operations, and most integration architectures aren't built for it.

Here's what France did: companies exchange invoices directly through PEPPOL — but each side also must send a summary to the French tax authority's portal. Not one model or the other. Both, at once.

Fethi doesn't think this is a one-off. "We'll see more of these hybrid systems," he told me, "and that will make data architectures even more complex." Europe's ViDA initiative pushes consistent digital reporting across the EU; Singapore has its own PEPPOL access point through IMDA; Australia's ATO runs its own version. None identical, none staying still.

Why "just add a country adapter" doesn't scale

The instinctive response is to bolt on a connector: map your ERP's invoice object to whatever XML schema the authority wants, wire it into your PEPPOL access point, ship it. Works for jurisdiction one. Even two, if you're disciplined.

It stops working once each jurisdiction's hybrid model — its own mix of peer-to-peer exchange and regulatory reporting, its own validation rules, its own timing — becomes a bespoke integration path. Fethi's phrase for it: "every entity that needs to send or receive an invoice will have very, very unique specific context requirements that will not be easy to determine." Multiply that across jurisdictions and your integration layer is really N integration layers wearing the same UI.

The real question isn't "which standard do we adopt" — it's "how do we absorb a new jurisdiction's hybrid model without a rewrite." Fethi's own answer leans on proven, unglamorous technology: microservices, APIs, BPM engines, XML transformation, chosen for capacity to evolve, not novelty. The mistake I'd flag for a CTO: treating that stack as a destination rather than a discipline. The value is in a pluggable, versioned mapping and validation layer, separate from your core invoice data model, so a new country's rules are configuration, not a new codebase.

Where agents might help — and where they clearly can't yet

Fethi raised, then qualified, giving agentic systems autonomy here — letting software decide how to handle an exception instead of every case being hand-coded. His caveat matters as much as the idea: "this is not well sort of stable and proved technology... we need more experimentation." Honest, from someone who researches this for a living.

Where I'd draw the line: deterministic fields — product codes, quantities, prices, things Fethi and Alan agreed shouldn't be touched by anything generative — stay in your rules engine. A novel exception, or an edge case your rules didn't anticipate, is a legitimate frontier for agents, with the same discipline any agentic system needs in a regulated data flow: bounded actions, logged decisions, a human in the loop until the pattern's proven.

If you're expanding into new markets, or a regulator is signalling a hybrid model like France's, the expensive mistake is building your integration around this year's single-country requirement. Cheaper: build the abstraction layer first — treat "which jurisdiction, which obligation, which validation ruleset" as data your system consumes, not logic baked into your pipeline. Get it wrong and it won't show for eighteen months, by which point you're maintaining five hand-built country integrations and the person who understood the trade-offs has moved on. Worth having someone who's seen a hybrid regime like France's break a system's assumptions look at the design before jurisdiction two, not after.