e-Factura integration with ANAF

e-Factura through Romania's ANAF SPV has been mandatory for B2B since July 2024 and for B2C since January 2025. A B2B invoice that does not pass through the system is no longer a legal invoice and carries penalties. I built the full integration into a product that runs in production, so I know where the traps are, not just what the guide says.

What I deliver

The integration covers both directions, not only sending:

• Issuing. The invoice is generated as UBL 2.1 XML compliant with the RO_CIUS 1.0.1 profile, built on EN16931, uploaded to the SPV, tracked through to validation, and the response signed by the Ministry of Finance is downloaded.
• Receiving. Supplier invoices are pulled automatically from the SPV, parsed, and matched against the documents already in accounting, so nothing gets keyed in twice.
• OAuth2 authentication with automatic token refresh, bootstrapped from the digital certificate used once to authorize the app in the SPV.

How it works, in short

The real ANAF flow is not a single call. An issued invoice goes through:

1. Upload (upload) - you send the UBL XML and get back an upload index.
2. Status query (stareMesaj) - you poll for whether it was accepted, rejected, or is still processing.
3. Download (descarcare) - once it is ready, you fetch the ZIP archive containing the invoice plus the Ministry of Finance electronic signature.

On the receiving side, the message list (listaMesaje) returns the invoices that have arrived, with a maximum 60-day window per query; for longer periods you use the paginated variant. Each message is downloaded, unzipped, and the UBL inside is read.

The details that make the difference

The things that break rushed integrations:

• The ANAF access token is valid for ~90 days, the refresh token for a year. If renewal is not automatic, one day the invoices stop going out and nobody knows why, and once the refresh token expires too you have to redo the certificate authorization in the SPV. Here the renewal is automatic, with retry on 401 and protection against concurrent access.
• Reverse charge (Art. 331). It is encoded distinctly in the UBL, with the exemption reason, otherwise the invoice is rejected at validation.
• Multiple VAT rates on one invoice. The breakdown by rate (21% standard, 11% reduced, exempt) is grouped and totalled correctly in the tax section.
• The downloaded archive holds two files - the invoice and the signature. You need to know which is which and keep the original for audit.
• Matching received invoices against manually entered ones is done strictly, on supplier fiscal code plus number plus total, with a tolerance, so you do not create duplicates.

Built into a real product

All of this runs in Manag.Web, the business-management platform I build and maintain as my own product, in production at several Romanian companies. It issues and receives invoices daily, with automatic synchronization of documents arriving from the SPV - a shipping product, not a demo.

The product documentation, including the invoicing and compliance parts, is public: manag.zbconsulting.eu.

Who it is for

If you have an ERP, an invoicing app, or an in-house system that needs to talk to the ANAF SPV - whether you are starting from scratch or an existing integration behaves unpredictably - I can take this part end to end: from UBL generation to the full status and receiving flow. I integrate into your existing system rather than asking you to replace it.

See also SAF-T (D406) reporting, the other ANAF obligation I implement from the same system.