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.

The most common e-invoice rejection reasons

The technical patterns that cause validation failures are documented from a developer perspective in The Hidden Complexity of E-invoicing: A Developer's Guide to Data Validations. From an operational standpoint, most of those failures trace to a smaller set of root causes in how data is collected and maintained.

Missing or incorrect mandatory fields

Every invoice framework, whether UBL, Peppol, or a national mandate, specifies a set of required fields. The fields most commonly missing or incorrect are not obscure: supplier tax registration numbers, buyer tax registration numbers, invoice dates, and tax amounts. These fields fail not because teams do not know the requirements, but because the data was never collected correctly at onboarding, was never validated at source, or was not kept current as customer records changed.

Invalid or unverified tax IDs

A tax ID that fails format checks produces an immediate rejection. A tax ID that passes format checks but is no longer active in the relevant tax authority registry produces a rejection at the semantic validation stage, often with a less informative error message. Both failures share the same root cause: the ID was collected once and never verified against the registry it belongs to.

Tax calculation errors

Tax calculation failures are among the most operationally costly rejections because they indicate a systemic problem rather than a one-off data error. A customer classified with the wrong tax treatment generates incorrect invoices until the record is corrected. A product mapped to the wrong tax rate produces errors at scale. These failures repeat until the underlying classification is fixed.

Duplicate invoice detection

Tax authorities and buyer systems both check for duplicate invoice numbers. This becomes a problem when retry logic resubmits a failed invoice without incrementing the invoice number, or when multiple systems generate invoices from the same numbering sequence without coordination. Duplicate rejections typically signal an integration design problem rather than a data quality problem.

Buyer-side rule mismatches

Beyond tax authority requirements, many buyers apply additional validation rules in their AP systems: purchase order references, cost center codes, vendor IDs. An invoice that passes the tax authority's validation may still be rejected by the buyer. These failures are harder to diagnose because buyer rules are not always documented and AP system error messages are often generic.

What Limehome learned: 99.9% invoice acceptance starts upstream

Limehome is a tech-enabled hospitality company that operates across Europe. As the business expanded from Germany and Spain into Italy, Portugal, and further markets, its invoicing infrastructure did not keep pace. The stack consisted of multiple local, siloed providers that required constant manual intervention to keep running.

The cost showed up in engineering time. Some weeks, internal engineers were spending up to 70% of their time resolving invoicing issues: debugging rejections, chasing missing invoices, and reconciling inconsistencies across providers. Invoicing had become a full-time job for people hired to build product.

Fragmented vendors also meant no single view of e-invoicing performance. Each provider reported on its own region, making it impossible to identify rejection patterns globally or trace systemic issues to their source.

Limehome adopted Fonoa's E-Invoicing solution in 2025, going live in Italy in 26 working days, a week ahead of deadline. With a single integration across markets, consistent pre-submission validation, and clear visibility into any failures, the acceptance rate shifted substantially.

"Fonoa makes it really easy to see why something was rejected. Plus, with the extensive validation, rejections don't happen nearly as often as before."
— Karen Yip, Product Manager (Payments), Limehome

The outcomes:

• 99.9% invoice acceptance rate, including in highly regulated markets
• Over 3,600 manual invoice reviews eliminated per year
• Approximately 1,000 hours saved per year across accounting, engineering, and back office
• 90% reduction in engineering time spent on invoicing issues
• €50,000 saved per year in internal time costs

Those results came from removing the conditions that produced rejections in the first place, not from getting faster at handling them after the fact.

"Fonoa lets us sleep at night. We don't have to worry about compliance while we scale."
— Karen Yip

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.