oneapi
Sign in
Anaf v1 / e-Factura

Read invoice

From a CIUS-RO invoice it extracts the business data as JSON, with the same keys you would send to build. For reading received invoices without touching the XML.

POST
https://oneapi.ro/api/anaf/v1/efactura/parse

Request body

The request body is the whole document, sent raw (Content-Type: application/xml) — not an object with fields.

UBL CIUS-RO invoice

efactura.xml application/xml · 4,0 KB — sent as is, in the request body.

Corrected invoice

efactura-corectata.xml application/xml · 4,0 KB — sent as is, in the request body.

A credit note

efactura-stornare.xml application/xml · 3,6 KB — sent as is, in the request body.

An invoice in euro

efactura-intracomunitara.xml application/xml · 4,2 KB — sent as is, in the request body.

Query parameters

This route accepts no query parameters.

How it behaves

  • The document can also be sent as a file: multipart/form-data with the fisier field (curl -F fisier=@document.xml), instead of the raw body. The file content becomes the request body, so the result is identical; options stay in the query string, and any other form field next to fisier returns 422 camp_necunoscut.
  • Takes a CIUS-RO invoice XML and returns the matching business JSON — seller, buyer, lines, rates, totals. It is the inverse of /anaf/v1/efactura/build: together they make the JSON ⇄ XML round-trip.
  • The typical use is reading a received invoice: instead of parsing the UBL by hand, you ask here for the business structure already extracted and work with it. The JSON returned has the same shape build accepts, so you can regenerate, edit or compare it.
  • The round-trip now also covers the blocks that used to be dropped: the payee (BG-10), the tax representative (BG-11), the attached documents (BG-24, base64 content included), the prepaid amount and the payment rounding.
  • The exception is the exchange rate: UBL does not carry it explicitly, so we derive it from the cac:TaxTotal pair (VAT in the invoice currency and the same VAT in RON). It comes out exact to 4 decimals only when VAT is non-zero; on a zero-VAT invoice (intra-community supply, export) there is nothing to derive it from, so it is absent — and build will ask for it back, explicitly.
  • Zero retention: the XML received is not written and not logged; parsing is stateless and in-memory.
  • An XML that cannot be parsed (not well-formed, or not a recognizable CIUS-RO invoice) returns 422 in the common {eroare:{cod,mesaj,camp}} shape.

What it is for

  • Reading an invoice received from a supplier, without writing a UBL parser.
  • Round-trip: parse an invoice, edit a field, regenerate it with build.
  • Extracting totals and lines for import into an accounting system.

Response structure

FieldTypeDescription
data object The invoice business JSON — the same shape build accepts (seller, buyer, lines, rates, totals).
data.type string The requested document type.
data.number string
data.issue_date string
data.due_date string
data.currency string
data.supplier.name string
data.supplier.vat_id string
data.supplier.address.street string
data.supplier.address.city string
data.supplier.address.county string
data.supplier.address.country string
data.customer.name string
data.customer.vat_id string
data.customer.address.street string
data.customer.address.city string
data.customer.address.county string
data.customer.address.country string
data.lines[].id string
data.lines[].name string
data.lines[].quantity integer
data.lines[].unit string
data.lines[].unit_price integer
data.lines[].vat.rate integer
data.lines[].vat.category string
meta.generat_la string When the response was built (ISO 8601).

Response examples

body: @efactura.xml

POSThttps://oneapi.ro/api/anaf/v1/efactura/parse
{
    "data": {
        "type": "invoice",
        "number": "FCT-2026-0142",
        "issue_date": "2026-09-10",
        "due_date": "2026-10-10",
        "currency": "RON",
        "supplier": {
            "name": "Exemplu Furnizor SRL",
            "vat_id": "RO990000005",
            "address": {
                "street": "Str. Memorandumului 28",
                "city": "Cluj-Napoca",
                "county": "RO-CJ",
                "country": "RO"
            }
        },
        "customer": {
            "name": "Exemplu Client SRL",
            "vat_id": "RO990000072",
            "address": {
                "street": "Calea Victoriei 1",
                "city": "SECTOR1",
                "county": "RO-B",
                "country": "RO"
            }
        },
        "lines": [
            {
                "id": "1",
                "name": "Servicii de consultanţă",
                "quantity": 2,
                "unit": "H87",
                "unit_price": 100,
                "vat": {
                    "rate": 21,
                    "category": "S"
                }
            }
        ]
    },
    "meta": {
        "generat_la": "2026-10-06T23: 59: 42+03: 00"
    }
}

Error codes

CodeSlugWhen it occurs
401neautentificatToken missing, invalid, expired or revoked.
403feature_indisponibilThe current plan does not include the feature the route depends on.
422xml_invalidThe body is not parsable XML or is not a recognizable CIUS-RO invoice.
429cota_depasitaThe plan's monthly quota has been exceeded (see Retry-After).

Errors in the Anaf module use the same envelope as the rest of the platform, with two extra fields: {eroare: {cod, mesaj, camp, request_id}}. eroare.cod is stable and is what you branch on; on validation (422) the code is case-specific: xml_invalid, xml_nu_e_factura, unitate_necunoscuta, luna_invalida and so on. camp points at the offending field when one can be identified.

{
    "eroare": {
        "cod": "xml_invalid",
        "mesaj": "The body is not parsable XML or is not a recognizable CIUS-RO invoice.",
        "camp": null,
        "request_id": "0199c1f0-6e1a-7c3d-9b2f-4a8e5d1c7b04"
    }
}