Cum transmiteți o factură electronică prin API

Dacă sistemul dumneavoastră contabil generează deja facturile, le puteți transmite în SIA „e-Factura” prin API, fără ca cineva să le reintroducă. Pagina descrie fluxul așa cum îl documentează ghidul de integrare al SFS.

Baza legală: N/A — nicio afirmație juridică pe această pagină. Pagina descrie cum funcționează un sistem al statului. Nu spune cine este obligat să emită facturi electronice și nu enunță niciun termen.

Ce vă trebuie înainte

1. Un utilizator API — cum se creează.
2. Un sistem care poate produce conținutul facturii în format XML.

Pasul 1 — autentificarea

Sistemul dumneavoastră trimite numele de utilizator și parola printr-o conexiune securizată HTTPS. Platforma returnează un token de sesiune, folosit apoi pentru toate apelurile ulterioare.

Ghidul descrie conexiunea ca basicHttpBinding cu securitate TransportWithMessageCredential.

Pasul 2 — transmiterea facturii

Metoda documentată este PostInvoices. Ce trimiteți:

Dacă factura are documente atașate (contracte, avize), ghidul documentează o metodă separată, PostInvoicesWithAttachment, care transmite factura împreună cu fișiere PDF.

Structura XML-ului nu o reproducem aici. Ghidul conține un exemplu complet, dar este un exemplu — nu o schemă normativă — iar exemplarul din ghid este un caz particular (cu cantități și sume negative), pe care nu vrem să îl prezentăm drept forma obișnuită a unei facturi. Citiți-l direct în ghid, la secțiunea 5.12.

Pasul 3 — ce vă răspunde platforma

Răspunsul la PostInvoices conține, printre altele:

• TotalInvoices — câte facturi ați trimis;
• TotalInvoicesPosted — câte au fost preluate cu succes;
• Status — 1 acceptat pentru executare, 2 executat cu succes, 3 eroare la executare;
• ErrorMessage — mesajul de eroare, dacă este cazul. Exemplele date în ghid: XML incorect și eroare la procesare.

Citiți cele două numere, nu doar statutul. Dacă TotalInvoicesPosted este mai mic decât TotalInvoices, o parte dintre facturi nu a intrat, iar un sistem care nu compară cele două valori va raporta un succes care nu s-a întâmplat. Este cea mai ieftină greșeală de evitat din tot fluxul.

Pasul 4 — semnarea, care nu se face prin API

Ghidul spune explicit, în introducere, că în varianta semiautomatizată operațiunile finale — semnarea, anularea sau respingerea — se realizează manual, direct în interfața web, de către persoanele autorizate. (Pentru anulare și respingere, această afirmație intră în contradicție cu alte două secțiuni ale aceluiași ghid — vedeți „Ce nu deținem".)

Transmiterea prin API nu semnează nimic. Există o metodă, GetInvoicesForSigning, care returnează facturile pregătite pentru semnare, dar actul semnării rămâne în interfața web.

În practică asta înseamnă că fluxul are un pas uman, iar cineva trebuie să știe că are facturi de semnat. Platforma nu îl anunță pe e-mail — problemă raportată SFS de EBA Moldova în 2024.

Pasul 5 — confirmarea

Pentru a verifica ce s-a întâmplat cu o factură, ghidul documentează:

• CheckInvoicesStatus — statutul facturilor emise;
• SearchInvoices — căutare după criterii generale (număr, serie, dată, statut);
• GetInvoicesBySeriaNumber — căutare după seria și numărul facturii.

Ce înseamnă codurile returnate: statutul XML și ciclul de viață al facturii.

Ce nu deținem

• Nu am executat niciunul dintre acești pași. Descriem un document, nu o experiență.
• Adresa serviciului apare în ghid doar într-o captură de ecran a fișierului web.config, nu în text.
• Nu există o schemă XML normativă în ce am citit — doar un exemplu.
• Ghidul se contrazice în privința anulării și a respingerii, iar noi nu alegem între variante. Introducerea spune că semnarea, anularea și respingerea se fac manual, în interfața web. Același ghid documentează însă metodele PostCanceledInvoices (§5.11) și PostRejectedInvoices (§5.14), care transmit prin API facturile anulate, respectiv refuzate. Ambele afirmații sunt în același document. Nu știm care descrie comportamentul real al serviciului — dacă metodele consemnează o acțiune făcută în interfață sau o pot declanșa — și nu deducem răspunsul. Dacă proiectați un flux de anulare, verificați la SFS înainte de a vă baza pe oricare dintre cele două citiri.

Pentru oricare dintre acestea, verificați la SFS.

Vezi și

• Integrare 1C cu e-Factura — în cluster D4; pagina nu este încă scrisă
• Plugin WooCommerce pentru e-Factura — în cluster D4; pagina nu este încă scrisă
• Cum creați un utilizator API în e-Factura (cross-cluster D2 — pasul dinaintea acestei pagini)

depus este în dezvoltare. Pașii de mai sus se execută integral împotriva platformei statului; nu există încă niciun API al nostru, nicio cheie și niciun mediu de test pe care să le puteți folosi.

Verificat la: 2026-08-17

Acest material are caracter informativ și nu constituie consultanță juridică sau fiscală. Pentru situația concretă a companiei dumneavoastră, adresați-vă unui consultant autorizat sau instituției competente.

Stadiu: în recenzie