ANAF e-Invoicing and EDI: How the Two Systems Fit Together

What e-Factura and e-Transport actually require

ANAF's e-Factura system requires businesses to submit invoices in a structured UBL 2.1 XML format through the national RO e-Factura platform, rather than relying solely on a PDF or paper invoice sent directly to the buyer. Separately, e-Transport requires advance electronic notification of certain categories of goods movement before the transport takes place, with the goal of giving tax authorities visibility into supply chains in near real time. Both systems apply regardless of whether a company also exchanges documents electronically with its retail trading partners.

Neither e-Factura nor e-Transport was designed with retail EDI in mind, and neither replaces it. A supplier selling into Kaufland, Carrefour or Auchan still needs to send an EANCOM-format INVOIC message that matches the retailer's own specification, purchase order references and product coding, while also submitting the tax-compliant UBL 2.1 version of essentially the same invoice to ANAF. These are two separate technical formats describing the same commercial event.

Where the overlap creates risk

The practical risk is not that the two systems conflict on paper, it is that maintaining them as two independent processes creates opportunities for the figures to drift apart. If the retailer-facing invoice is generated from one dataset and the ANAF submission from another, entered separately or exported at different times, discrepancies in quantities, pricing, VAT treatment or invoice numbering can appear, which becomes a genuine compliance headache during a tax audit or a retailer reconciliation dispute.

This risk grows with volume. A supplier issuing a handful of invoices a month can probably catch a mismatch manually, but a supplier issuing hundreds of retail invoices monthly across several retailers needs the two outputs to be structurally linked to the same source data, or the reconciliation burden becomes a permanent, recurring task for the finance team rather than an occasional check.

Generating both from a single source

The more robust approach is to treat the underlying commercial invoice — line items, quantities, prices, VAT, buyer and seller details — as the single source of truth, and generate both the EANCOM INVOIC for the retailer and the UBL 2.1 e-Factura submission for ANAF from that same record. This does not eliminate the need to understand both formats, since each has its own mandatory fields and validation rules, but it removes the risk of the two documents silently diverging because they were entered or maintained twice.

A connectivity platform that supports both retailer EDI and e-Factura generation from shared order and invoice data effectively turns what would otherwise be two separate compliance projects into a single workflow, with one point of data entry and two compliant outputs. This is particularly valuable for suppliers who are simultaneously onboarding new retailer EDI connections and adapting internal processes to e-Factura obligations, since doing both at once with disconnected systems multiplies the coordination work.

Sequencing the work if you are starting from scratch

For suppliers who have neither system in place yet, it is usually more efficient to scope e-Factura compliance and retailer EDI connectivity together rather than sequentially, even if the retailer connection is the more urgent deadline. Mapping the retailer's INVOIC specification and ANAF's UBL 2.1 schema at the same time, against the same underlying invoice data model, tends to surface field-level questions — like how discounts, VAT categories or partial deliveries should be represented — that are far easier to resolve once than twice.

If a hard retailer deadline forces Web EDI or ERP integration to go live first, it is still worth confirming with the connectivity provider that e-Factura generation can later plug into the same data model without requiring a second, disconnected invoicing setup. Asking this question early avoids a rebuild a few months down the line.

Practical checklist for suppliers

Before finalizing an EDI or invoicing project, it is worth confirming a short list of points with whichever platform or internal team is responsible for compliance, since gaps here are what typically surface later as reconciliation problems rather than as upfront blockers.

• Can retailer invoices and ANAF e-Factura submissions be generated from the same order data?
• Is VAT treatment consistent across both the EANCOM INVOIC and the UBL 2.1 submission?
• Are invoice numbering sequences aligned so the same commercial invoice is traceable in both systems?
• Does the platform handle e-Transport notifications where applicable to the goods being shipped?
• Who is responsible for updating both formats if ANAF or a retailer changes its specification?

FAQ

Does e-Factura replace the need for retailer EDI invoices?

No. e-Factura is a tax reporting requirement to ANAF using the UBL 2.1 format; retailer EDI invoices (typically EANCOM INVOIC) are a separate commercial exchange with the trading partner and are still required.

Can the same invoice data be used for both e-Factura and EDI invoices?

Yes, generating both formats from the same underlying invoice record is possible on a platform designed for it, and it reduces the risk of mismatched figures between the two.

What happens if the EDI invoice and the e-Factura submission do not match?

Mismatches can create disputes with the retailer over amounts owed and complications during a tax audit, since ANAF and the retailer may hold different figures for what should be the same commercial transaction.

Is e-Transport relevant to EDI-connected suppliers?

It can be, for suppliers moving goods that fall under e-Transport's scope. It runs alongside EDI and e-Factura as a separate advance-notification requirement for certain goods movements.