e-Factura, e-Transport and SAF-T integration for the systems you already run

Romanian tax reporting obligations are not solved by somebody uploading files into the ANAF portal at the end of the month. They are solved by an integration that sends documents from the system where they are created, confirms what was accepted and tells you when something was rejected.

Most companies start with a temporary arrangement: an export from the invoicing software, a manual upload into the Virtual Private Space (SPV), and somebody checking now and then that everything went through. It holds until the volume grows. Then come the forgotten invoices, the rejections discovered two weeks later, and a month-end reconciliation done by putting two lists side by side.

We connect the system that issues the documents directly to the ANAF API. The invoice is generated in the required format, goes out automatically, and the response comes back into the system: accepted, rejected, with the reason. We don’t replace your accounting software and we don’t ask you to change your process — we add the reporting layer on top of what you have.

The hard part isn’t the API call, it’s everything around it: credit notes, advance payments, line-level discounts, reverse charge, VAT on collection, customers without a VAT number, units of measure that have to be mapped onto the official nomenclatures. This is where quick integrations get stuck, and where the time goes if it isn’t handled from the start.

What we build

Issuing e-Factura through the SPV

XML generated in the RO_CIUS format (UBL 2.1), authentication with your own digital certificate, transmission over the ANAF API and retrieval of the response message. Every document has a status you can verify, not one you assume.

Receiving supplier invoices

Automatic download from the SPV, matching against the purchase order or the goods receipt, and a flag when the price or the quantity doesn’t line up. Incoming invoices land in the system without being typed a second time.

e-Transport and the UIT code

Declaring shipments and obtaining the UIT code before the goods leave, with updates when the route or the quantity changes. Tied to the delivery note and the waybill, so it isn’t a second parallel record.

SAF-T — the D406 return

Extracting the data from your own databases, mapping it onto the required nomenclatures and validating the file before submission. The structure is built once and regenerated every reporting period.

Reconciliation and alerts

One view of what was sent, what was accepted, what was rejected and why. Automatic retries on communication errors and an alert by email or WhatsApp on rejections. Nothing stays unresolved without you knowing.

Integration with what you use today

Invoicing software (SmartBill, Oblio, FGO), an online store on WooCommerce or PrestaShop, your own business application, or the company ERP where it exposes an API or an accessible database. Where it doesn’t, we discuss the realistic option before promising anything.

Technologies

Standards

  • UBL 2.1 / RO_CIUS
  • XML & XSD validation
  • SAF-T D406
  • Electronic signature

Integration

  • ANAF API (SPV)
  • OAuth 2.0 with certificate
  • REST & SOAP
  • Queues and retries

Backend

  • Java 21 & Spring Boot
  • PHP & Laravel
  • PostgreSQL / MySQL
  • Audit log

Operations

  • Docker
  • Scheduled runs
  • Alerts on rejections
  • Archiving for the legal term

We don’t replace your accounting software and we don’t hold your digital certificate. We build the layer between your system and ANAF; the credentials stay with the company.

A good fit if

  • you upload invoices into the SPV by hand and the volume has outgrown what one person can track
  • you have an online store or a business application that issues invoices and you want them to go out on their own
  • you ship goods that fall under e-Transport and somebody in the office requests each UIT code manually
  • you have received mismatch notifications and have no quick way to see what was sent and what wasn’t

Frequently asked questions

Doesn’t my accounting software already handle this?

Partly, in many cases. Plenty of packages send the invoice but never pick up the response, don’t reconcile at month end, don’t cover credit notes and advances, or only do it through a manual file upload. The first step is a short assessment of what your software already covers — if it is enough, we say so and don’t sell you an integration you don’t need.

How long does an e-Factura integration take?

For a straightforward issuing flow with ordinary documents: typically 2–4 weeks, tested in the ANAF test environment before a single real document goes out. It takes longer once the special cases appear — reverse charge, advances, credit notes, foreign-currency invoices — because each has its own completion rules.

What happens when ANAF rejects an invoice?

The rejection arrives as a message with the reason for the error. The system flags it, notifies you and keeps the full history of attempts; you correct the document and it is resent. The difference from working by hand is that you find out the same day, not at month-end close.

Do you need the company’s digital certificate?

Yes — communication with the SPV is authenticated with a qualified certificate registered to the company. It stays yours and configured on your server. We install it together with you and document the renewal procedure, so you don’t depend on us when it expires.

Can you cover SAF-T as well if we already have e-Factura?

Yes, and it is usually cheaper afterwards, because the data has already been cleaned once. SAF-T is a periodic extraction from the same databases, mapped onto the official nomenclatures and validated before submission. The work is in the mapping, not in the generation.

Let’s get specific

Do you have a project like this?

Message us on WhatsApp or by email with two or three sentences about what you need. We’ll come back with the questions that matter and a budget and timeline estimate.

No obligation, no follow-up pressure.