In a previous article, The Hidden Complexity of E-invoicing: A Developer's Guide to Data Validations, I walked through the seven patterns of e-invoicing validation.

But validation only tells you what's wrong. It doesn't fix anything.

Consider this scenario: Your invoice passes validation. Every required field is present, formats are correct, amounts balance out. You submit to the tax authority and wait for… A rejection. 

This time it's not a validation error. Portugal requires a specific VAT exemption disclaimer you didn't include. Or Argentina needs your amounts rounded to exactly two decimal places using banker's rounding. Or Saudi Arabia expects a cryptographic hash you have no idea how to generate.

This is the enrichment problem. Even when your data is valid, it's often not complete or correctly formatted for each jurisdiction's specific requirements. And unlike validation, enrichment isn't about catching errors. It's about transforming your data into exactly what each tax authority expects.

The gap between valid and compliant

Validation asks: "Is this data acceptable?"

Enrichment asks: "Is this data ready for submission?"

The distinction matters. A transaction amount of 125.4567 might be perfectly valid. It's a number, it's positive, it's within acceptable ranges. But Argentina's tax authority expects exactly two decimal places. Romania allows eight decimal places for unit prices.

Your data is valid. It's just not compliant.

This gap exists across virtually every aspect of e-invoicing: formatting, sequencing, tax calculations, addresses, digital signatures, legal text, and document classification. Each jurisdiction has specific expectations that go beyond "is this field present and correctly typed."

Nine types of e-invoicing enrichment

Looking across jurisdictions, enrichment falls into recognizable patterns. Each represents logic you'd otherwise need to build and maintain in your own codebase.

1. Formatting and standardization

Tax authorities are particular about how data looks, not just what it contains.

Spain, Portugal, and Hungary require tax numbers without country code prefixes, even though the standard format includes them. Portugal wants postal codes in a specific pattern (XXXX-XXX). Taiwan and Canada each expect timestamps in their local time zones and formats.

These aren't validation failures. Your data is correct. It just needs transformation before submission.

2. Sequence and number generation

Many jurisdictions require invoice numbers to follow specific patterns and maintain strict sequential ordering.

Portugal and Spain mandate sequential invoice numbers following tax authority patterns. Taiwan and Costa Rica require country-specific unique identifiers. Portugal's ATCUD compliance adds another layer of series management and validation codes.

If you're operating across multiple countries, you're potentially managing several different numbering schemes, each with its own rules about format, sequence gaps, and reset periods.

3. Tax calculation and aggregation

Even when you provide tax rates, authorities often expect the data presented in specific ways.

Costa Rica, Brazil, and Argentina require tax regimes mapped to country-specific codes. PEPPOL networks need rounding adjustments calculated and included separately. Nigeria and India expect tax breakdowns computed into individual components.

You might know the tax rate is 18%. But does your invoice include the tax broken down by component? Is the rounding adjustment calculated correctly? Are the codes mapped to what the authority expects?

4. Address and geographic enrichment

Addresses require more than just presence. They need standardization and validation against local requirements.

India and Mexico require state names converted to official tax authority codes. You might say "Delhi," but the authority expects "DL." Mexico maps postal codes to time zones for date calculations. Portugal and India have specific address field requirements that vary by transaction type.

5. Digital signatures and cryptographic elements

Some jurisdictions require cryptographic proof of invoice authenticity: signatures, hashes, and QR codes that your system needs to generate.

Saudi Arabia and Malaysia require cryptographic signatures using private keys. Saudi Arabia also wants invoice hashes for integrity verification. Canada and Saudi Arabia expect QR codes containing encrypted transaction data.

This isn't enrichment in the traditional sense, but it's data your invoice needs that you're unlikely to generate yourself without specialized infrastructure.

6. Regulatory compliance additions

Tax authorities often mandate specific legal text or disclaimers based on transaction characteristics.

Portugal requires VAT exemption explanations that match your tax codes. Romania and Canada have mandatory regulatory disclaimers. Spain restricts certain operation regimes to specific geographic areas.

These aren't optional. Missing a required disclaimer can mean rejection or compliance issues discovered during an audit.

7. Transaction classification and mapping

Your internal transaction types need translation to each country's document taxonomy.

Ecuador and Italy have specific local document types (Factura, NotaCredito) that your transactions must map to. Brazil requires payment methods translated to local authority codes. Nigeria and others expect HSN codes and product classifications.

You might call it an "invoice." The tax authority might need it classified as one of fifteen different document types depending on the transaction characteristics.

8. Data completeness

Sometimes required fields can be derived from other data you've provided, if you know the rules.

Spain and Saudi Arabia can default invoice issue dates to the current timestamp when not provided. Spain derives fiscal year and period from invoice issue dates. Argentina validates and applies currency conversion rates. Portugal and Saudi Arabia maintain proper transaction chains by linking to previous documents.

9. Content sanitization

Text content often needs cleaning before submission.

Brazil requires HTML tags stripped from transaction notes. Multiple countries need special characters and diacritics handled correctly. Romania enforces maximum character limits on notes. Saudi Arabia has specific rules about line breaks in custom notes and descriptions.

The maintenance burden

You could build all of this yourself. For each country, you'd implement the formatting rules, manage the number sequences, calculate the tax breakdowns, generate the signatures, add the legal text, and map the document types.

Then you'd maintain it. When Portugal updates its ATCUD requirements or Saudi Arabia changes its QR code format, you'd update your system. You'd track regulatory changes across every jurisdiction you operate in. You'd test every enrichment rule against every transaction type.

This is the same calculus as validation, but arguably worse. Validation rules are at least documented by tax authorities. They'll tell you when something's wrong, eventually. Enrichment requirements are often implicit. You discover them when invoices get rejected for missing disclaimers or incorrect formats, and the error messages rarely explain what you should have included.

For enterprise engineering teams already managing complex ERP integrations, adding a layer of country-specific transformation logic creates ongoing maintenance overhead that scales with every new market you enter.

How Fonoa approaches enrichment

At Fonoa, we treat enrichment as a core part of the e-invoicing pipeline, not an afterthought.

You send invoice data in our standard model. Before submission, we apply the enrichments each jurisdiction requires: formatting, calculations, signatures, legal text. Three principles guide how we do this:

Data integrity. We don't create business data or change commercial intent. Enrichments work with the data you provide, applying rules and transformations but never inventing information.

Compliance-first. Every enrichment follows official tax authority rules for precision, formats, codes, and validations. We're implementing what each jurisdiction actually requires.

Deterministic. Enrichments are rule-driven, repeatable, and auditable. The same input produces the same output. You can trace exactly what was applied and why.

This means you send us an invoice with a tax rate of 18% and a transaction amount of 125.4567. For Argentina, we round to 125.46. For Romania unit prices, we allow up to eight decimals. For Portugal, we add the appropriate VAT disclaimer. For Saudi Arabia, we generate the hash and QR code. You get compliant invoices without building country-specific transformation logic into your application.

What this means for your integration

E-invoicing integration has two layers of complexity: validation (is this data acceptable?) and enrichment (is this data ready?).

You can build both yourself. You'll maintain validation rules across jurisdictions, update them when regulations change, and handle the branching logic of conditional requirements. Then you'll do the same for enrichment: formatting, calculations, signatures, legal text, document mapping.

Or you can treat both as infrastructure. Send standardized data, let the validation and enrichment layers handle jurisdiction-specific requirements, and keep your engineering effort focused on your core systems.

The 2am invoice failure becomes less likely when validation catches problems before submission. But it becomes even less likely when enrichment ensures your valid data is also complete, correctly formatted, and ready for each tax authority's specific expectations.

Validation tells you what's wrong. Enrichment makes it right.

‍