e-Factura through Romania's ANAF SPV has carried a B2B reporting obligation since January 2024, and since July 2024 a B2B invoice that does not pass through the system is not a valid invoice. B2C followed in January 2025. 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 changed in 2026

The obligation has kept moving, and a page written for 2025 no longer matches the law:

The transmission deadline is 5 working days, not 5 calendar days, since 1 January 2026 under OUG 89/2025 (Monitorul Oficial no. 1203 of 24 December 2025). The rule has two limbs: 5 working days from the invoice date, and not later than 5 working days from the issuing deadline in article 319(16) of the Fiscal Code. The count follows Regulation (EEC, Euratom) 1182/71, so the day of issue does not count and a period ending on a Saturday, Sunday or public holiday runs to the end of the next working day.
Invoices to taxable persons not established in Romania but registered here for VAT also go through RO e-Factura from 1 January 2026. Two exceptions stay out and both matter in code: fiscal receipts that qualify as simplified invoices, and invoices for intra-Community supplies where the buyer gives a VAT number from another Member State.
Individuals who identify themselves by CNP were due to enter the system on 1 June 2026, after a postponement from 15 January. That obligation was removed before it took effect. Law 88/2026, published in Monitorul Oficial no. 459 of 29 May 2026 and in force from 1 June 2026, makes RO e-Factura optional for them through a separate opt-in register, and does the same for special-regime farmers.

Both sides are exposed: 15% of the invoice total for an issuer that does not invoice electronically, and the same 15% for a recipient established in Romania that receives and books the invoice outside the system. Missing the transmission deadline is a separate and smaller offence, 1,000 to 10,000 lei depending on taxpayer size. None of these can be settled at half the minimum.

If your integration counts days with simple date arithmetic, the working-day rule is a change you have to make in code, not one you can absorb by filing earlier.

What I deliver

The integration covers both directions, not only sending:

Issuing. The invoice is generated as UBL 2.1 XML compliant with the CIUS-RO 1.0.1 profile (CustomizationID urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1), 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:

Upload (upload) - you send the UBL XML and get back an upload index.
Status query (stareMesaj) - you poll for whether it was accepted, rejected, or is still processing.
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.

I build the software that produces these files. I am not a tax advisor, and nothing here replaces advice from your accountant. Dates and versions on this page were checked against the ANAF and Ministry of Finance sources on 29 August 2026.