ERP propriu pentru companii românești: integrare ANAF, eFactura, SAF-T

01SPV și eFactura B2B: obligatoriu din 2024, dur din 2026

Din 1 ianuarie 2024, toate facturile B2B emise în România trebuie raportate în sistemul RO e-Factura prin SPV-ul ANAF. În 2025 și 2026, controalele au devenit sistematice, iar nerespectarea atrage sancțiuni proporționale cu cifra de afaceri. ERP-ul trebuie să transmită fiecare factură în format UBL 2.1 către SPV, să primească confirmarea, și să gestioneze eventualele erori de validare.

Tehnic, integrarea SPV-ANAF se face prin API REST cu autentificare bazată pe certificat digital calificat. Certificatul trebuie obținut de la un furnizor autorizat (DigiSign, CertSign, AlfaSign) și utilizat pentru semnătura electronică a fiecărei facturi. ERP-ul trebuie să gestioneze rotația certificatelor, expirarea, și să mențină un audit log complet al transmisiilor.

În plus, ERP-ul trebuie să gestioneze și primirea facturilor B2B de la furnizori prin SPV. Multe companii nu realizează că obligația este bidirecțională: dacă un furnizor îți transmite factura prin SPV, trebuie să o procesezi corect, să o importi în sistemul tău, și să o reflectezi în contabilitate. Lipsa primirii corecte generează discrepanțe în declarațiile fiscale.

02SAF-T D406: declarația lunară pe care nu o poți greși

SAF-T, cu declarația D406, este sistemul prin care companiile transmit lunar (sau trimestrial, în funcție de pragul de venituri) către ANAF un fișier XML standardizat care conține toate înregistrările contabile, facturile, mișcările de stoc, plățile, încasările. Pentru companiile mari și mijlocii, obligația este lunară din 2023. Pentru micro și mici, etapizat începând din 2025.

Fișierul SAF-T are sute de tag-uri obligatorii. Generarea lui corectă din ERP cere o mapare riguroasă între planul de conturi românesc, clasificarea TVA, codurile de produs și serviciu, partenerii cu CUI valid, și înregistrările contabile per zi. O greșeală sistematică în mapare generează respingerea fișierului sau audituri suplimentare din partea ANAF.

ERP-urile generice internaționale au probleme serioase cu SAF-T românesc pentru că modelul lor de date nu se pliază perfect pe specificul OMFP 1783/2021. Un ERP construit nativ pentru România generează SAF-T corect din prima, cu validări automate, alerte preventive, și posibilitatea de regenerare istorică. Această capacitate justifică deseori singură decizia de custom.

• →Mapare completă plan de conturi românesc OMFP 1802/2014
• →Validări automate înainte de transmisie pentru fiecare D406
• →Regenerare istorică pentru perioade auditate
• →Audit log complet pentru toate exporturile SAF-T
• →Detectarea automată a inconsistențelor între submodule

03e-Transport și gestionarea bunurilor în mișcare

Sistemul RO e-Transport este obligatoriu pentru transporturile de bunuri cu risc fiscal ridicat, dar lista categoriilor se extinde anual. În 2026, majoritatea transporturilor B2B de mărfuri valoroase necesită raportare prin e-Transport înainte de plecare, cu codul UIT generat și transmis către șofer și destinatar. ERP-ul trebuie să comunice automat cu acest sistem.

Integrarea e-Transport cere ca ERP-ul tău să genereze pentru fiecare transport relevant: declarația de transport cu toate datele (transportator, vehicul, șofer, ruta, mărfuri, valoare, partener), să o transmită prin API către SPV-ANAF, să primească codul UIT, să îl atașeze automat documentelor de însoțire, și să gestioneze eventualele modificări sau anulări înainte de plecare.

Pentru companii cu volum mare de transporturi, această integrare nu este opțională. Manual, declarațiile durează 15-30 minute fiecare; automatizat din ERP, durează secunde. Pentru un distribuitor cu 200 transporturi pe zi, diferența este între un departament suplimentar și un proces complet automat. ROI-ul integrării e-Transport într-un ERP serios apare în câteva luni.

04Sincronizare cu SmartBill, Oblio și sistemele de facturare existente

Multe companii românești folosesc deja SmartBill sau Oblio pentru facturare și nu vor să le abandoneze. Un ERP propriu modern nu trebuie să le înlocuiască, ci să se sincronizeze bidirectional. SmartBill expune un API REST complet pentru creare, citire, modificare facturi. Oblio are un API similar, mai recent. Integrarea permite ca ERP-ul să genereze facturile, SmartBill să le emită oficial către SPV-ANAF, iar statusul să se actualizeze automat în ambele sisteme.

Această arhitectură hybrid funcționează bine pentru companii care vor să își păstreze contabilul fericit cu SmartBill, dar care au fluxuri operaționale complexe în ERP. Comenzile, ofertele, contractele, livrările stau în ERP. Facturile se generează acolo, dar emitearea oficială rămâne în SmartBill cu numerotarea ei legală. Sincronizarea evită dublarea datelor și menține o sursă unică de adevăr pentru fiecare proces.

Pentru companii care vor să elimine SmartBill sau Oblio, ERP-ul propriu poate prelua complet rolul, cu integrare directă în SPV-ANAF. Decizia depinde de complexitatea proceselor contabile și de relația cu firma de contabilitate. Firma de IT Blackbone evaluează ambele scenarii la începutul fiecărui proiect ERP și recomandă arhitectura potrivită pentru fiecare client.

05Arhitectura tehnică: stack, securitate, audit

Un ERP românesc serios în 2026 rulează tipic pe un stack Next.js sau Remix pentru frontend, NestJS sau FastAPI pentru backend, PostgreSQL pentru date, Redis pentru cache și sesiuni, plus o coadă de joburi (BullMQ sau Sidekiq) pentru procesările asincrone către ANAF. Hosting-ul preferat este într-un cloud cu prezență europeană: AWS Frankfurt, Google Cloud Brussels, sau provider românesc precum ClicSoft sau Adriatic.

Securitatea este non-negociabilă. ERP-ul conține date fiscale critice, certificate digitale, și acces la SPV-ANAF. Standardul minim include: autentificare cu MFA obligatoriu pentru toți utilizatorii, RBAC granular cu separarea rolurilor financiar/operațional/admin, encryption at rest pentru baza de date, encryption in transit cu TLS 1.3, audit log imutabil pentru toate acțiunile critice, backup-uri zilnice cu retenție de minim 7 ani.

Auditul este al treilea pilon. Un ERP românesc trebuie să poată produce, la cerere, un raport complet pentru o perioadă auditată de ANAF: toate facturile emise, toate facturile primite, toate exporturile SAF-T, toate transmisiile e-Transport, toate corecțiile și anulările, cu timestamps exacte și utilizatorii care au efectuat acțiunile. Această capacitate de audit nu este opțională, ci o cerință legală.

06Cum livrează firma de IT Blackbone proiectele ERP românești

Echipa Blackbone abordează fiecare proiect ERP în 4 faze. Prima fază, discovery, durează 4-6 săptămâni și produce o specificație tehnică completă, modelul de date, integrările obligatorii, planul de migrare a datelor existente. A doua fază, MVP, livrează în 3-4 luni nucleul ERP-ului cu modulele core: produse, parteneri, comenzi, facturare, integrare SPV pentru eFactura.

A treia fază, lunile 5-9, extinde la modulele specifice clientului: stocuri multi-locație, producție, planificare, achiziții, integrări cu sisteme externe, SAF-T complet, e-Transport. A patra fază, post go-live, asigură stabilizarea, training-ul utilizatorilor, integrarea în fluxul real, și dezvoltarea continuă a features noi în sprinturi lunare.

Investiția tipică pentru un ERP românesc serios este între 150.000 și 450.000 euro pentru versiunea inițială, cu mentenanță și dezvoltare continuă de 30-80.000 euro anual. Comparativ, un SAP Business One cu localizare românească și consultanță bună costă similar pentru implementare, dar adaugă 1.500-3.000 euro per utilizator pe an licențe perpetue. Pe 5 ani, ERP-ul propriu produce ROI clar pentru organizații peste 30 utilizatori.