How we integrate ANAF e-Factura into a custom ERP or a legacy program (2026 guide)

This guide is for companies that issue invoices from a system of their own: an online store, an ERP or inventory program without an e-invoicing module, a custom-built application or even a well-kept Excel file. By the end you know what ANAF requires, which integration paths exist, what each technical step involves, which mistakes come up most often, and how long a proper integration takes and what it costs. Updated in September 2026.

What ANAF requires, in short

• Every invoice goes through the e-Factura system. For business-to-business invoices since July 2024, for invoices to consumers since January 2025. The official invoice is the one in the SPV portal, not the PDF sent by email.
• The format is XML UBL 2.1 with the Romanian CIUS-RO rules. A PDF, an Excel sheet or an invoice from an old program has to be converted into that XML.
• The submission deadline is at most five days from issue. Delays are fined per invoice, between RON 1,000 and 10,000 depending on the company’s category.
• Supplier invoices arrive in the same portal and stay downloadable for 60 days. A complete integration brings them into your system instead of someone downloading them by hand.
• VAT rates in 2026 are 21% (standard) and 11% (reduced). The XML declares them on every line and totals them per rate.

The three integration paths

1. Directly to the ANAF API

Your system generates the XML, sends it to ANAF, tracks the status and downloads the responses. You get full control, zero intermediary subscriptions and your own log of every invoice. This is the right path for an ERP, an online store or a custom application that already issues the invoices. The rest of this guide describes it.

2. Through the invoicing program you already use

Programs such as SmartBill, Saga or Oblio have e-invoicing built in. When the invoices actually originate in another system, the integration is an automatic export from your system to the invoicing program, which submits them. It works well when the invoicing program remains the accounting source and you want one place where all invoices are visible.

3. Through an intermediary API

Some services handle the ANAF authorisation, the XML conversion and status tracking for you, for a monthly fee. They reduce the integration work to a few simple calls. The recurring cost and one more vendor to depend on are the price of that simplicity.

The steps of a direct integration

1. Enrolment with ANAF

The company needs a qualified digital certificate registered in the SPV portal (the administrator’s or the accountant’s, with a mandate for the company) and an OAuth application registered in the ANAF portal, which yields a client ID and a secret. With the certificate, the application obtains an access token valid for 90 days and a refresh token valid for a year. The token is stored encrypted, renewed automatically before it expires, and an email alert announces when the renewal needs the certificate again.

2. Generating the XML

The invoice is built as a UBL 2.1 Invoice document with the CIUS-RO customisation identifier:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1</cbc:CustomizationID>
<cbc:UBLVersionID>2.1</cbc:UBLVersionID>

The fields that cause the most trouble, in the order they show up in practice:

• Company identification: the tax ID with the RO prefix for VAT payers and without it for the others, the exact name from the trade register, the address with the county code (for Bucharest, the sector goes in the city field).
• Invoice lines: quantity with a unit from the UN/ECE code list (for example H87 for piece, C62 for unit), unit price, VAT category and rate on every line.
• VAT totals per rate and category: standard, reduced, exempt, reverse charge. Rounding happens at total level, not per line, otherwise validation rejects one-cent differences.
• Currency: invoices in another currency also declare the VAT equivalent in RON at the National Bank rate of the issue date.
• Linked documents: reversals and corrective invoices reference the original invoice and use the proper document type.

3. Validation before submission

ANAF provides a public validator, without authentication, that checks the XML against the schemas and the CIUS-RO rules:

POST https://webservicesp.anaf.ro/prod/FCTEL/rest/validare/FACT1
Content-Type: text/plain

[the invoice XML]

For testing the whole flow there is the test environment https://api.anaf.ro/test/FCTEL/rest/, with the same authorisation as production. That is how testing stays legal: the validator and the test environment accept any invoice, while production receives only real invoices.

4. Submission and status tracking

POST https://api.anaf.ro/prod/FCTEL/rest/upload?standard=UBL&cif=43340189
Authorization: Bearer {token}
Content-Type: text/plain

[the invoice XML]

→ <header index_incarcare="5001234567" ExecutionStatus="0"/>

The upload index is saved on the invoice. It is used to poll the status until ANAF finishes processing:

GET https://api.anaf.ro/prod/FCTEL/rest/stareMesaj?id_incarcare=5001234567

→ stare="in prelucrare" | "ok" (with id_descarcare) | "nok" (with id_descarcare for the errors)

On ok, the archive downloaded with descarcare?id= contains the invoice XML and the Ministry of Finance signature; it is the official document and belongs in the company archive. On nok, the same archive contains the list of errors, shown in your system next to the invoice.

5. Invoices received from suppliers

GET https://api.anaf.ro/prod/FCTEL/rest/listaMesajeFactura?zile=7&cif=43340189

→ messages of type FACTURA PRIMITA, FACTURA TRIMISA, ERORI FACTURA, MESAJ CUMPARATOR

A daily job picks up the new messages, downloads the received invoices and imports them into inventory or accounting, with the supplier, the lines and the VAT already filled in. Messages stay in the portal for 60 days, so automatic download also protects the archive.

6. Log, alerts and retries

• Every invoice has a visible status: to send, sent, accepted, rejected, with the date and time of each change.
• Submission is idempotent: an invoice that was already uploaded has its index saved and is never sent twice.
• Temporary network or API errors are retried automatically with growing pauses, while definitive ones reach a person.
• Email alerts cover three situations: a rejected invoice, an unsent invoice close to the legal deadline, a token about to expire.

The errors we see most often

• Tax ID mismatch between token and invoice. The token belongs to a certificate with rights on certain companies; the invoice is submitted with the issuing company’s cif, exactly as registered in the portal.
• Incomplete addresses. A missing county code or a wrongly entered Bucharest sector are the most frequent validation rejections.
• One-cent rounding. Totals computed per line and summed differ from the total per rate; the correct rule is computing on the total.
• Invented units of measure. “pcs” or “hours” instead of the codes from the code list.
• Double submission. A button pressed twice without a saved index produces two identical invoices in the portal, and the fix requires a reversal.
• Silently expired token. After 90 days submissions fail without anyone noticing; that is what the expiry alert is for.

What it means for an old program without an API

Many companies invoice from a program written years ago that works perfectly but knows nothing about ANAF. The integration is built next to it, from whatever the program offers:

1. Export (CSV, XML, DBF): a job reads the exported files at a fixed interval and builds the XMLs.
2. An accessible database (Access, SQL Server, MySQL, Firebird): the integration reads the issued invoices directly, with read-only rights.
3. Screen only: as a last resort, UI automation that clicks in place of a person. It works, but needs maintenance at every change of the program.

From the company’s side, the integration needs: invoice series and numbering, complete customer data (tax ID, address with county), VAT rates per product or service and units of measure. Cleaning that data is usually half the project.

How long it takes and what it costs

On the Romanian market, an integration starts at RON 2,000–5,000 for a system with an export or a documented API and rises towards RON 10,000 and beyond for old programs without documentation, or for flows with several companies and two-way synchronisation. Our connected e-invoicing package starts at RON 2,500 and is ready in 10 working days: connecting the invoice source, automatic submission, reading the responses, supplier invoices from the portal, email alerts, short documentation and one hour of training. If your source needs extra work, we say the price before we start.

Checklist before starting

1. Who holds the digital certificate and for which companies it has rights in the portal.
2. Where the invoices originate today: program, store, Excel, several sources.
3. What the system can provide: API, export, database, screen only.
4. Which VAT rates and special cases occur: exemptions, reverse charge, foreign currency, advances, reversals.
5. How many invoices per month are issued and how many are received.
6. Who must be notified on a rejection and who corrects the invoice.
7. Where the signed XMLs are archived and for how long.
8. How testing is done: validator, test environment, then the first real invoice, followed together.

Frequently asked questions

Is a digital certificate needed for every company?

The certificate belongs to a person who has rights in the portal for one or more companies. An accountant with a mandate can authorise the application for all their clients, and the application submits for each company with its own tax ID.

Can I test without sending real invoices?

Yes. The public validator checks the XML, and the ANAF test environment accepts the whole flow with real authorisation. Production receives only invoices that were genuinely issued.

What do I do with a rejected invoice?

Fix the cause in your system and resubmit the same invoice; a rejection at validation means the invoice never reached the portal. An accepted invoice with wrong data is corrected through a reversal and a new invoice.

Does it work from Excel?

Yes, if the file has stable columns: customer data, series and number, lines with quantity, price, VAT rate and unit. A job reads the file, builds the XML and submits it. It is a good transition solution until an invoicing system is in place.

Who keeps the invoices?

Your company. The signed archive downloaded from ANAF is kept in your system for the retention period required by accounting law. The copy in the portal is available for only 60 days.