ANAF e-Factura

Start (re)authorizing this server with ANAF when the grant is dead or about to end. Returns authorizeUrl for the CERTIFICATE HOLDER to open in a browser with the qualified digital certificate; you cannot do that step. Then call complete_authorization with the address the browser lands on, within 60 seconds of it landing. Starting again replaces an earlier begun authorization.

Write a Romanian e-Factura invoice (UBL 2.1, CIUS-RO) from fields: seller and buyer, lines with their net price, quantity and VAT category, the currency, the payment terms. Totals are computed exactly (each line rounded to 2 decimals, VAT once per category and rate), and the draft is checked first: CIF, CNP and IBAN check digits, the county and Bucharest sector, the VAT rules per category, CIUS-RO's lengths, every problem named at once. The file goes to the outbox; the answer gives its path, sha256 and totals. Nothing is sent to ANAF: next, validate_invoice with xml: { path }, then upload_invoice with the same path to file it. An invoice in another currency needs vat_exchange_rate (RON per unit), so its VAT is stated in RON too.

Finish what begin_authorization started: exchanges ANAF's code for tokens and stores them where this server keeps them. Pass the whole address the browser landed on as redirect_url (or code and state). Answers only the two expiry dates; no token ever appears in the result. ANAF's code dies 60 seconds after it is issued, so call this at once.

Download the signed ZIP for a message id from list_invoices and save it to the downloads outbox (a name holding another file gets a number, never overwritten). The archive is checked first: it must open with every entry matching its checksum and hold the document with ANAF's seal (semnatura_*.xml), and the seal is checked against the document. Returns the path, bytes, sha256 and md5 of the archive, each entry's name, bytes and sha256, the seal's verdict, and what the invoice says.

File an e-Transport declaration XML (ANAF's schema v2) with ANAF: a new transport (notificare), its correction (notificare with corectie), a deletion (stergere), a receiver's confirmation (confirmare) or a vehicle change (modifVehicul), whichever the file holds. The XML as xml: { path } for a file, or { content_base64, sha256 } from a script. Goes to ANAF's TEST environment unless test is explicitly false. A money tool (a fiscal declaration): the client asks the user to approve each call, on a line read out of the file (operation, UIT, route, vehicle, goods value in RON, environment). The declarant's code and any UIT must pass their check digits. Returns accepted, the uploadId etransport_status takes and the UIT, or accepted=false with ANAF's reasons; the UIT counts only once etransport_status says ok. The same bytes are not filed in production twice unless refile is true. Needs the ETRANSPORT role on the grant. Moves money or makes a legal document: the client asks the user to approve each call.

List e-Transport declarations from the last N days (at most 60): UIT code, declarant, trading partner, carrier, vehicle, and refused=true with ANAF's messages for a declaration it rejected. A notice field means ANAF refused or had nothing. Separate from e-Factura: it needs the ETRANSPORT role on the same grant.

How an e-Transport declaration filed with etransport_file was processed, by its uploadId: state ok (the UIT is valid from now), processing, or failed with ANAF's reasons. Ask the environment it was filed in: test unless test is false.

Check that the integration is alive and say so in detail: the ANAF app it authenticates as, the CIF it defaults to, the roles the grant carries, and how many days are left on each token. Run this before concluding the MCP is broken.

Have ANAF render an invoice as its official PDF and save it to the downloads outbox. Give message_id (from list_invoices) for a filed invoice, or a UBL document as xml ({ path } for a file, or { content_base64, sha256 } from a script). A filed invoice is not validated again; a document is validated first unless validate is false, and when it fails nothing is saved and findings say why. Returns saved, path, bytes and sha256 of the PDF. The PDF itself needs no grant; fetching a filed invoice by message_id does.

List e-Factura messages from the last N days (ANAF allows at most 60). Each message has a kind (sent, received, error, buyerMessage), an id that download_invoice takes, a zoneless local timestamp, and details: the upload id, issuer CIF and beneficiary CIF lifted out of ANAF's prose. A notice field means ANAF refused rather than returned nothing.

List messages over an inclusive YYYY-MM-DD window, paginated, in the same shape as list_invoices plus page counters. The window may span at most 60 days and is read as UTC. filtru narrows by type: E errors, T sent, P received, R awaiting a response.

Look up companies in ANAF's public VAT registry by CIF: name, trade register number, registered office, CAEN code, and the statuses an invoice depends on (vatPayer with its current period, vatOnCollection, splitVat, inactive, and eFacturaRegistry for the RO e-Factura registry). notFound lists the CIFs ANAF does not know. A status ANAF did not report is absent, not false. Needs no grant.

Read a UBL invoice or credit note into plain JSON: seller and buyer (names, VAT and legal ids, address, contact), every line (quantity, unit, price, net amount, VAT category and rate), the VAT breakdown, the totals, and the payment terms (due date, terms, IBAN). Every value is the document's own text, amounts included, never a number; a field the document does not fill is absent. Give xml ({ path } for a file, or { content_base64, sha256 } from a script) or archive, a .zip download_invoice saved to the outbox. Reads only: nothing goes to ANAF. To have ANAF check the document, use validate_invoice.

Mint a new access token. Does nothing while the current one still has its three-day cushion unless force is set, because every refresh also ROTATES the refresh token and the old one dies with it. Safe to call on a schedule; pointless to call in a loop.

Report on the stored OAuth tokens without contacting ANAF and without refreshing. Watch refreshTokenRemainingDays: once it reaches zero the grant can only be restored by hand, at a browser, with the qualified certificate.

Submit an invoice (UBL or CII XML) to ANAF, given as xml: { path } for a file, or { content_base64, sha256 } from a script. Every IBAN in it must pass its check digits. Goes to the TEST environment unless test is explicitly false, because a production upload is a filing that cannot be recalled. A money tool: the client asks the user to approve each call, on a line read out of the XML itself (number, date, buyer, amount due, the file's sha256). Returns accepted plus the uploadId that upload_status takes, or accepted=false with ANAF's reasons; sha256 and bytes of what was filed; invoice is what the XML says, and raw is ANAF's answer verbatim. The same bytes are not filed in production twice unless refile is true. Moves money or makes a legal document: the client asks the user to approve each call.

Submit an invoice issued to a PERSON, not a company (B2C), through ANAF's /uploadb2c: the same as upload_invoice in every other way. The XML as xml: { path } (build_invoice's path works) or { content_base64, sha256 } from a script; every IBAN must pass its check digits. Goes to the TEST environment unless test is explicitly false. A money tool: the client asks the user to approve each call, on a line read out of the XML and marked B2C. Returns accepted plus the uploadId upload_status takes, or accepted=false with ANAF's reasons. The same bytes are not filed in production twice, by either upload tool, unless refile is true. Moves money or makes a legal document: the client asks the user to approve each call.

Check how an earlier upload was processed, by the uploadId that upload_invoice or upload_invoice_b2c returned. Answers a state of ok, processing or failed, with a downloadId once it is ok. Must be asked of the same environment the upload went to.

Check a UBL invoice or credit note against ANAF's own schema and CIUS-RO rules without filing it. Answers valid, and when not, findings: each with the rule it broke (e.g. BR-RO-001), where in the document, and ANAF's text. invoice is what the XML says it is, and file which file was read (name, size, sha256). Needs no grant. CII is not accepted: ANAF validates UBL only. The document goes as xml: { path } for a file, or { content_base64, sha256 } from a script.

Check that an invoice is the file ANAF stored, under ANAF's seal (semnatura_*.xml). Give ONE of: message_id (downloads the archive: ANAF allows 10 downloads a day per message), archive (a .zip already in the downloads outbox, from download_invoice; costs nothing), or the two files from an archive kept elsewhere (costs nothing): xml and signature, each { path } or { content_base64, sha256 }, read byte for byte, since the seal covers the invoice's exact bytes. Checked locally first: the certificate against Trans Sped's seal CA and the Ministry of Finance, the signature, and the digest of the invoice's raw bytes. Only when that cannot decide is ANAF asked. Answers valid, checkedBy (local or anaf), a reason when not valid, and the certificate. Revocation is not checked locally.