Why the Notebook Is Essential for Complex E-Invoicing Projects — and How AI Agents Turn It into a Delivery Method

Implementing e-invoicing is one of the most cross-functional programmes a company can undertake. It touches tax, accounting, procurement, sales, information systems and third-party master data, and now, with e-reporting obligations, data itself as a regulatory object. In this context, traditional project tools (spreadsheets, Word documents, Jira tickets, specification slides) quickly reach their limits: they artificially separate code, data, reasoning and decisions.

The notebook, whether Quarto, R Markdown, Jupyter or Observable, fills precisely that gap. It replaces neither functional documentation nor production code, but it becomes the natural place where teams think with data. Here is why it is not just useful but necessary for the analysis, design and prototyping phases of an e-invoicing project, and how, once connected to AI agents, it becomes the backbone of an end-to-end delivery method.

1. E-invoicing is first and foremost a data problem

Behind the apparent simplicity of the topic, "sending and receiving invoices in a structured format", lies a much rougher reality:

• Millions of historical invoices to qualify in order to calibrate the rules.

• Third-party reference data (SIREN, intra-EU VAT numbers, country codes, unit codes, tax codes) to cross-check and clean.

• Multiple business flows (direct sales, intermediated sales, expense reports, credit notes, self-billing, pro forma invoices), each with distinct tax rules.

• Data from invoicing tools that must remain consistent with data in the accounting system(s): reconciliation of amounts, VAT chargeability dates, document numbers and analytical axes. This consistency is itself subject to control and, increasingly, to regulatory transmission. It is all the more critical because the tax authority can now verify it directly, matching e-invoicing and e-reporting flows against VAT and corporate tax returns and, during an audit, against the FEC (French audit file) itself.

• Edge cases (French overseas territories, intra-EU transactions, exports, margin scheme VAT, reverse charge), each a small share of volumes but a disproportionate share of risk.

None of these topics can reasonably be handled without working on the data itself. And as soon as you work on data, you need an environment that combines code, results and commentary: the very definition of a notebook. This is also exactly where AI agents connected to the client's data sources start to pay off, as section 7 shows.

2. The notebook makes reasoning verifiable

In an e-invoicing project, the smallest assumption has regulatory consequences. A typical example: "how many of our outgoing B2B invoices issued outside the EU will fall within the e-reporting scope?" The answer drives:

• The sizing of the chosen e-invoicing platform.

• The workload plan for the accounting teams.

• The choice between a PDP (Plateforme de Dématérialisation Partenaire, the certified platform) and an OD (Opérateur de Dématérialisation, a non-certified service provider).

• The wave-based migration strategy.

If this figure is produced in an isolated spreadsheet, nobody can reconstruct it six months later: the exact query, the filters applied, the period chosen, the treatment of credit notes or internal re-invoicing. In a notebook, by contrast, every published figure is backed by its code, its joins and its explicit assumptions. The reasoning becomes auditable, which is both a methodological requirement and, increasingly, a compliance requirement.

3. The notebook is the right format for the design phase

Designing an e-invoicing project runs into a paradox: the target rules (what the standard requires) are clear, but the source rules (what the company's data actually says) almost never are. Theoretical data models must therefore be constantly confronted with the reality of existing systems.

A notebook enables exactly this back-and-forth:

• You write a mapping hypothesis (for example: VAT code 20S corresponds to the standard domestic rate).

• You test it immediately against the database: how many lines follow the rule, how many deviate, what the exceptions are.

• You document the decision taken (keep, fix at source, create a transcoding rule, isolate for manual handling).

• Everything stays in a single document, readable by a functional analyst, a tax specialist or an architect.

This iterative way of working cannot be reproduced with a static specification document. A Word spec says what the system should do; a notebook shows what the data actually does. The two are complementary, but one does not replace the other. With LLMs connected to the real data, this loop now also produces the specification and the mapping tables themselves, generated from and checked against actual records.

4. The notebook accelerates prototyping and de-risks industrialisation

Before deploying a production pipeline that generates, validates, signs and transmits Factur-X invoices, you need to have prototyped:

• Reading and writing the target XML formats (UBL, CII).

• Schema validation (XSD) and business-rule validation (Schematron).

• Enrichment from external reference data (INSEE, VIES).

• Error handling (rejection by the PPF, the public invoicing portal; rejection by a recipient PDP; internal inconsistency).

• VAT consistency checks, rounding, totals.

Prototyping these building blocks in a notebook has three advantages. First, the feedback loop is short: you can test a rule on a sample in seconds instead of redeploying a full job. Second, the notebook serves as a living test book: the cases tested, edge cases included, remain attached to the demonstration. Third, code prototyped in a notebook transfers directly to industrialisation: useful functions are extracted into a package, and unit tests derive naturally from the notebook's examples.

In R with {quarto} or {rmarkdown}, this transition is particularly smooth: the notebook can load an in-house package under development via devtools::load_all(), test its functions, and those same functions move into the package without friction.

The notebook connected to AI via MCP: a change of scale

This prototyping advantage is being multiplied by a recent development: the ability to connect the notebook to an AI model (Claude, ChatGPT, Gemini) via the Model Context Protocol (MCP). In practice, MCP servers such as r-mcp, or mcptools on the R side, expose a real execution environment to the AI: the R interpreter, the notebook's live session, access to data and reference tables, and sometimes the underlying Oracle or SAP database. The AI no longer merely suggests code: it can run it, observe the results, fix its errors and iterate on its own until it produces a working script.

Applied to e-invoicing, this changes the economics of prototyping. Starting from a heterogeneous body of documents (Factur-X specifications in PDF, a mapping grid in Excel, a tax scoping note in Word, sample invoices in an XML archive), the AI can recursively:

• Read and structure the rules extracted from the documentation.

• Generate a first version of the mapping, validation or consistency-check functions.

• Run these functions on a real sample through the MCP server.

• Identify gaps, exceptions and cases the documentation does not cover.

• Fix the code, rerun the tests and document the choices in the notebook.

The notebook then becomes an object co-produced by the analyst and the AI: the human asks the question, sets the rules and arbitrates ambiguous cases; the AI industrialises the code → execution → debugging loop that, until now, took up most of the time. The gain is not only speed but also reliability, because every function produced has been executed, tested against real data and documented in context. This avoids the two classic flaws of e-invoicing projects: code that "looks right" without ever being proven, and specifications that remain theoretical because nobody had time to test them against the data.

This is not automation in place of the expert. It is an amplifier that lets the tax or functional expert cover, in the same time, a scope of rules and a volume of cases that were previously out of reach.

From prototyped interface to production programme

One last, often underestimated barrier also falls thanks to this AI + MCP combination: moving from prototype to production. In an e-invoicing project, interfaces prototyped in an R (or Python) notebook must sooner or later be rewritten in the target language of the production environment: typically PL/SQL for an Oracle EBS component, ABAP for an SAP component, sometimes Java or Python for a dedicated integration layer. This rewrite has historically been one of the most costly and risky parts of the project: it requires scarce profiles, introduces deviations from the functionally validated prototype, and creates a testing debt that must be paid in full.

AI connected to an MCP server changes this equation. Once the R prototype is stable and proven in the notebook, the AI can:

• Automatically translate the R logic ({dplyr} transformations, joins, validation rules) into the target platform's language: an equivalent PL/SQL query, an ABAP module with its internal structures, or an integration job in the chosen ETL.

• Use the production environments' MCP servers (Oracle MCP, SAP MCP) to run the translated code, compare results with the R prototype, and iterate until strict line-by-line equivalence is reached.

• Generate in parallel the non-regression test set that guarantees the production version produces exactly the same results as the prototype on the samples already validated.

The notebook thus becomes the project's functional source of truth, and production code becomes a verifiable translation of that source. You move from a rewrite logic, where each team reinterprets the spec, to assisted transpilation, where the gap between prototype and production is measured, not assumed. In an e-invoicing project where the same tax rules must coexist across several systems (ERP, e-invoicing platform, reporting tool), this equivalence guarantee is especially valuable: it eliminates an entire class of bugs caused by divergent interpretations between environments.

5. The notebook as a communication tool with stakeholders

An e-invoicing project brings together profiles who speak different languages: tax specialists, accountants, IT, integrators, software vendors, master-data owners, internal control. Giving each of them an appropriate view is a governance challenge in itself.

Once rendered (HTML, PDF, Word), the notebook is the only format that can simultaneously:

• Show the figure (what business teams expect).

• Show the logic that produced it (what audit and IT ask for).

• Tell the story (what project leadership needs to communicate).

An isolated Excel table does not say how it was built. A slide does not say where the figures come from. A Jira ticket does not tell the journey. A notebook, by contrast, condenses all of this into a single, versioned artefact that is, a detail that matters in a regulated environment, reproducible.

6. Reproducibility is no longer optional

French e-invoicing obligations introduce a principle that goes well beyond the technical: the company's ability to demonstrate, on request, that the figures transmitted to the tax authority were produced according to the declared rules. This requirement maps directly onto data-science best practice: versioning, a frozen environment, executable code, replayable results.

A notebook stored in a Git repository, with a managed environment ({renv} in R, uv or pip-tools in Python), ticks all these boxes. A spreadsheet shared on a drive, unversioned and edited simultaneously by several people, ticks none. Choosing the notebook is therefore not cosmetic: it is a structural answer to a compliance challenge.

On top of reproducibility comes a dimension often underestimated at scoping time: the pace of change of e-invoicing systems once they are live. Feedback from countries that are already equipped, including Italy (SdI), Romania (RO e-Factura), India (IRP/GSTN) and Greece (myDATA), converges on the same finding: these systems undergo between 2 and 14 changes per year driven by regulatory developments (new formats, new mandatory fields, new thresholds, new validation rules, a wider scope of taxpayers, revised timetables). In other words, go-live is not the end of the project: it is the start of a permanent cycle of change, more frequent than for most other components of the information system.

A few concrete examples illustrate this density of change:

• Italy (SdI): since 2019, the system has gone through successive waves of extension and adjustment almost every year. Among the most visible milestones: cross-border reporting was integrated into SdI in July 2022 (new codes TD17 to TD19 and TD28 replacing the "esterometro"); micro-businesses and the "regime forfettario" were brought in from January 2024, removing any size-based exemption; and FatturaPA technical specifications v1.9 came into force in April 2025, introducing code TD29 for irregular supplier invoices and the new regime code RF20. Each change required simultaneous updates to issuing, receiving and accounting reconciliation systems.

• Romania (RO e-Factura): launched in September 2021 for B2G, the system was extended to high-fiscal-risk B2B in July 2022, generalised to B2B in January 2024, then extended to B2C in January 2025 through Emergency Ordinance No. 138/2024. Ordinance 89/2025, published at the end of December 2025, further changed the transmission deadline (from 5 calendar days to 5 working days) and introduced new registration obligations for sole traders from 1 January 2026. That is three to four structural changes a year for a relatively young system.

Absorbing 2 to 14 changes a year means being able, for each change, to:

• Analyse the existing setup quickly: which rules are in place, how they were calibrated, on which cases they were validated.

• Reproduce current results on a known dataset, to establish a baseline.

• Apply the change and measure the gap, rule by rule, rather than rediscovering the system at every cycle.

This triad (analyse, reproduce, evolve) is only achievable within tight deadlines if a notebook architecture has been in place from the design phase. Without it, every change becomes a mini-project again, with rules reinterpreted, manual recalibration and ad hoc tests. With it, a change means editing an identified set of cells, rerunning the notebook, checking the gaps and pushing the new version, while keeping an auditable trace of what changed, when and why. What is at stake when choosing the initial tooling is therefore not only a successful rollout: it is the marginal cost of every change over the following ten years.

7. Our method: an AI-native delivery model for e-invoicing

At Digital Business Solutions, the notebook is not a standalone tool: it is the backbone of a delivery method in which every phase relies heavily on AI. LLMs are connected to the client's systems and to our own tools through MCP servers, and an agent harness executes and checks the work. The notebook remains the functional source of truth throughout; the agents read from it, write to it and are held accountable against it.

1. Data analysis. We explore the client's existing data and processes (invoices, orders, EDI flows) with AI agents connected directly to the sources, in order to identify what can be digitalised. Every finding lands in the notebook with the query that produced it.

2. Prototyping. We use AI to build a working prototype quickly (flows, interfaces, screens, workflow) so the solution can be validated with business users on their own data, not on mock-ups.

3. Specification. Functional specifications and mappings are drafted, generated and verified with LLMs from the real data. Each mapping rule is tested against actual records before it is written down.

4. Implementation. The prototype's scripting is ported to the target applications (B2B platform, middleware/ETL, ERP) with the support of coding agents, which check line-by-line equivalence with the prototype through the target systems' MCP servers.

5. Testing and acceptance. Agents generate the test sets, run technical and business acceptance testing, and analyse and track defects in Jira.

6. Go-live. We prepare and secure the cutover, then check the first production flows as they arrive.

7. Operational steering. We provide functional steering and run the transitional arrangements in production. Flows are supervised, defects are picked up with agents connected to the systems, and communication with stakeholders (suppliers, customers, business teams) is automated through agents connected to the shared mailboxes.

8. Industrialised operations. The pilots and transitional arrangements are ported to the target platforms for long-term operation (monitoring, dashboards, automated processing). We then set up and industrialise corrective and evolutionary maintenance, using AI to automate processes, improve responsiveness and raise the quality of interventions.

The last phase closes the loop with section 6: when the next regulatory change arrives, the same agents replay the notebook on the baseline, apply the change, measure the gap rule by rule and propagate it to production. The 2 to 14 changes a year stop being mini-projects and become routine maintenance.

Conclusion

The notebook is neither a data scientist's gadget nor an intermediate format to be thrown away once production is live. In an e-invoicing project, it is the right tool for the phase where you need to understand (data analysis), the phase where you need to decide (design), and the phase where you need to try before industrialising (prototyping). It embodies a simple principle: in a project where data is at once the starting point, the working material and the regulatory deliverable, the steering tool must also be centred on data.

Connected to AI agents through MCP, the notebook goes further: it becomes the thread that runs from the first data exploration to industrialised operations, and the reference against which every agent's work is checked.

Adopting the notebook is not a matter of tool preference. It is a way of aligning how you work with the real nature of the problem you are solving.