Modulul de facturare într-un ERP la comandă: funcționare

Într-un ERP la comandă, facturarea nu e un modul izolat care așteaptă date introduse manual — e punctul unde comanda, contractul și livrarea devin bani de încasat. Când facturarea trăiește separat, într-un program de facturare de sine stătător sau într-un fișier paralel, apar decalaje: prețuri renegociate care nu ajung pe factură, cantități livrate parțial facturate integral, un abonament uitat o lună întreagă, un curs valutar greșit care distorsionează TVA-ul raportat. Fiecare dintre aceste erori pare mică izolat, dar se acumulează — în ore de reconciliere manuală la închiderea lunii, și, ocazional, în discuții incomode cu un client care primește o factură greșită.

Un modul de facturare integrat elimină acest decalaj: preia direct din comandă sau din contract regulile de preț, monedă și termen, și generează documentul fără ca cineva să retranscrie date dintr-un sistem în altul. Articolul acoperă mecanica operațională a modulului: emiterea din comenzi și contracte existente, facturarea recurentă pentru abonamente și contracte cadru, facturarea parțială pe proiect, valuta multiplă cu cursul BNR și fluxul de la proformă la factura fiscală. Ce nu acoperă: mecanica de transmitere a facturii către ANAF — format XML, praguri legale, termene de încărcare în SPV —, care e un subiect de conformitate fiscală, tratat separat.

Ce face, de fapt, un modul de facturare într-un ERP la comandă

Un modul de facturare nu e o interfață în care completezi manual poziții de factură. Rolul lui e să transforme automat un eveniment produs în alt modul — o comandă confirmată, un contract semnat, o etapă de proiect recepționată — într-un document de facturare, fără ca nimeni să retranscrie date.

De la comandă și contract la document de facturare, fără reintroducere de date

Practic, modulul citește: datele fiscale ale clientului (deja validate la onboarding), pozițiile comenzii sau ale contractului — produse sau servicii, cantități, prețuri unitare, discounturi negociate —, condițiile comerciale (termen de plată, monedă, cotă de TVA aplicabilă) și starea livrării sau a execuției (livrat integral, parțial, sau finalizată o etapă). Din aceste date compune automat proforma sau factura, cu o singură confirmare din partea operatorului.

Un exemplu simplu arată de ce contează: un client comandă 500 de unități la 12 lei/bucată, cu discount de 8% pentru volum, termen de plată 30 de zile. Dacă depozitul livrează doar 420 de unități în prima tranșă, un proces manual riscă să factureze fie cele 500 comandate — greșit, nu s-a livrat tot —, fie 420 la prețul de listă, fără discount — greșit din nou. Modulul de facturare, legat de comandă și de confirmarea de livrare, generează automat factura pentru 420 de unități, cu discountul de 8% aplicat corect, și lasă restul de 80 pentru o factură ulterioară, la următoarea livrare. Diferența față de „a factura manual" într-un program separat nu e viteza de completare — e faptul că sursa de adevăr pentru preț și cantitate rămâne comanda, nu o copie introdusă a doua oară, cu riscul ei de eroare.

Diferența față de mecanica de conformitate fiscală

Modulul descris aici răspunde la o întrebare operațională: cui, cu ce reguli de preț și monedă, pe ce flux intern se generează documentul. Nu răspunde la întrebarea „ce format XML trebuie să respecte factura odată generată și cum ajunge la ANAF" — asta e mecanica RO_CIUS, SPV și RO e-Transport, tratată la integrarea ERP cu e-Factura și ANAF. Cele două module colaborează — facturarea generează documentul, conformitatea îl transmite —, dar rezolvă probleme diferite, și un ERP la comandă le tratează ca atare, nu ca un singur ecran cu două responsabilități amestecate.

Emiterea facturii din comenzi și contracte existente

O factură emisă direct dintr-o comandă sau dintr-un contract moștenește automat toate deciziile comerciale deja luate — nu le renegociază la momentul facturării.

Reguli de preț și condiții comerciale moștenite din contract

Prețul unitar, discountul de volum, cota de TVA sau moneda de facturare nu se introduc din nou: vin din poziția comenzii sau din clauza contractuală corespunzătoare. Dacă un client are un contract cadru cu preț fix pentru un an, iar prețul de listă crește între timp, factura folosește prețul contractual, nu pe cel curent din catalog — exact cum ar trebui, comercial. Aceeași logică se aplică termenului de plată: dacă un contract prevede 45 de zile în loc de termenul standard de 30, factura moștenește 45 fără intervenție manuală, iar rapoartele de scadențe calculează corect data limită pentru fiecare client, nu una generică.

Validări automate înainte de emitere

Înainte ca documentul să devină factură, modulul verifică de regulă: cantitatea facturată nu depășește cantitatea comandată sau recepționată; cota de TVA aplicată corespunde tipului de produs sau serviciu și țării clientului, inclusiv cazurile de taxare inversă sau scutire pentru operațiuni intracomunitare; clientul nu a depășit limita de credit sau plafonul stabilit; seria și numărul facturii respectă secvența unică, obligatorie prin lege, fără goluri sau duplicate. Aceste verificări elimină cea mai mare parte a corecțiilor ulterioare. O factură greșită emisă către un client B2B care așteaptă transmiterea prin RO e-Factura e mult mai costisitoare de corectat — presupune stornare, reemitere și, uneori, explicații — decât una blocată la validare, înainte să existe.

Facturare recurentă: abonamente și contracte cadru

Un contract de mentenanță lunară, un abonament SaaS facturat trimestrial sau un contract cadru cu livrări periodice au ceva în comun: valoarea și structura facturii rămân, în mare parte, identice de la o perioadă la alta. Facturarea recurentă automatizează exact acest tipar — generează periodic documentul, fără ca operatorul să repete manual același proces în fiecare lună.

Cum se definește un ciclu de facturare

Modulul are nevoie de câteva date fixe la nivel de contract: valoarea — sau formula de calcul, dacă depinde de consum —, moneda, frecvența (lunar, trimestrial, anual), data de emitere în cadrul ciclului și, opțional, procentul de penalizare pentru întârziere la plată. Odată definit ciclul, sistemul generează automat fie proforme recurente — utile când vrei confirmarea plății înainte de factura fiscală —, fie facturi fiscale recurente direct, dacă relația contractuală nu cere pasul intermediar. Penalizările, când se aplică, se calculează de regulă la valoarea abonamentului, nu la suma totală neîncasată acumulată — altfel penalizarea „compune" nejustificat pe fiecare lună de întârziere.

Ce se întâmplă când se modifică un contract în mijlocul ciclului

Un client care își schimbă planul de abonament la jumătatea lunii, sau un contract cadru care primește un amendament de preț, nu trebuie să aștepte următorul ciclu ca schimbarea să se reflecte corect. Un modul de facturare bine construit calculează proratarea — partea din perioadă facturată la vechiul preț și partea facturată la noul preț — automat, pe baza datei de la care amendamentul intră în vigoare, fără ca cineva să recalculeze manual într-un tabel separat. La fel de important: sistemul trebuie să permită suspendarea sau anularea unui ciclu recurent fără să șteargă istoricul facturilor deja emise — un client care renunță la abonament nu trebuie să lase în urmă găuri în istoricul de facturare. Fără această logică, orice modificare de contract în timpul lunii devine o sursă de erori de facturare recurente, iar reconcilierea lor manuală consumă exact timpul pe care automatizarea trebuia să-l elimine.

Facturare parțială pe proiect

Pe un proiect facturat integral la finalizare, banii ies din execuție luni întregi înainte să intre în cont. Facturarea parțială pe etape — sau „pe procent de execuție" — rezolvă exact problema asta, dar cere ca modulul de facturare să știe, la orice moment, cât din proiect e deja facturat.

Facturare pe stadiu de execuție: procent sau cost

Există două metode uzuale de a stabili cât se facturează la o etapă: procentul de servicii executate din totalul contractat, sau proporția costurilor înregistrate până la acel moment din costul total estimat al proiectului. Ambele sunt valide — alegerea ține de tipul proiectului și trebuie stabilită explicit în contract, nu lăsată la interpretare la fiecare etapă. Un exemplu: un proiect de implementare cu valoare totală de 240.000 lei, structurat pe trei etape — analiză, dezvoltare, go-live —, facturat 25% la finalul analizei, 50% la finalul dezvoltării și restul de 25% la go-live. Fiecare factură parțială e însoțită, de regulă, de o situație de lucrări sau un document echivalent care arată exact ce s-a livrat sau executat până la acea dată — nu doar o sumă, ci un stadiu verificabil pentru client. Modulul trebuie să păstreze acest istoric per proiect: ce s-a facturat deja, la ce procent, și cât rămâne.

Reconcilierea cu avansul și cu factura finală

Dacă proiectul a pornit cu o factură de avans — să spunem 20% la semnare —, fiecare factură parțială ulterioară trebuie să „consume" o parte din avansul deja facturat, nu să îl ignore: practic, avansul se regularizează proporțional cu fiecare etapă facturată, până se epuizează complet. La finalul proiectului, factura finală închide diferența dintre valoarea totală a contractului și tot ce a fost deja facturat pe parcurs, inclusiv eventuala garanție de bună execuție reținută pe durata etapelor — un procent, adesea 5-10%, păstrat până la acceptanța finală. Un modul care nu ține evidența automată a acestei reconcilieri lasă loc pentru dublă facturare sau, la fel de rău, pentru sume „uitate" nefacturate la închiderea proiectului — iar pe un proiect cu execuție de câteva luni, diferențele astea nu se mai observă cu ochiul liber într-un tabel.

Valută multiplă și cursul BNR

Un contract în euro sau dolari cu un client sau furnizor nu înseamnă că factura poate ignora leul. Legea cere ca suma de TVA colectată să fie exprimată în lei chiar și atunci când restul facturii e în valută — deci modulul de facturare trebuie să știe să facă această conversie corect, nu doar să afișeze un simbol de monedă diferit.

Ce curs se folosește și de ce data facturii contează

Pentru majoritatea operațiunilor exprimate în valută, regula fiscală standard e „ultimul curs de schimb comunicat de BNR" — adică nu cursul zilei curente, ci cel comunicat de bancă în ziua anterioară și valabil pentru ziua în care se desfășoară operațiunea (BNR publică noul curs în jurul orei 13:00, valabil de a doua zi). Într-o zi nelucrătoare, se folosește cursul comunicat în ziua anterioară zilei respective. Contractele pot totuși specifica explicit un alt curs de decontare — de exemplu cursul băncii prin care se face plata, sau cursul BNR plus un procent fix — iar când o fac, modulul trebuie să respecte cursul contractual, nu pe cel implicit, altfel suma din factură nu se potrivește cu ce așteaptă clientul conform contractului.

Ce rămâne fix și ce se recalculează

Un detaliu ușor de ratat: dacă o factură se emite înainte de livrarea bunurilor sau prestarea serviciului — inclusiv o factură de avans —, cursul de schimb folosit la data emiterii rămâne neschimbat până la definitivarea operațiunii, chiar dacă între timp cursul BNR variază. Practic, sistemul trebuie să „înghețe" cursul folosit pe fiecare document emis, nu să recalculeze retroactiv la cursul curent atunci când vine factura finală sau de regularizare. Pentru un contract cadru facturat lunar în valută, asta înseamnă că fiecare factură din ciclu poate avea, legitim, un curs diferit — iar un raport care însumează facturile fără să păstreze cursul per document ajunge la o sumă în lei greșită, chiar dacă fiecare factură individuală e corectă.

Proformă → factură fiscală la confirmarea plății

Pentru clienți noi sau tranzacții cu risc de neplată, emiterea directă a facturii fiscale înainte de a vedea banii creează două probleme: riscul de neîncasare rămâne, iar TVA-ul devine exigibil chiar dacă suma nu a intrat încă în cont. Fluxul proformă → confirmare plată → factură fiscală rezolvă ambele.

De ce o proformă nu e un document fiscal

Factura proformă nu e reglementată de Codul Fiscal — nu are un format obligatoriu, nu generează obligații contabile sau fiscale și nu obligă clientul la plată. Exact din acest motiv, ea nu se transmite prin RO e-Factura; sistemul acceptă doar facturi fiscale. Rolul ei e pur informativ: comunică prețul, cantitățile și condițiile înainte ca tranzacția să devină reală din punct de vedere fiscal — practic o confirmare de comandă cu aspect de factură, care protejează furnizorul de un client care nu plătește niciodată.

Fluxul automat de la confirmarea plății la factura fiscală

Practic, modulul emite proforma la confirmarea comenzii, urmărește încasarea — manual confirmată sau reconciliată automat cu extrasul bancar — și, la confirmarea plății, generează factura fiscală cu aceleași poziții, fără reintroducere de date, doar cu conversia de la document informativ la document fiscal. Legea nu impune un termen fix între proformă și factura fiscală; termenul practic e stabilit de fluxul intern sau de contract. Pentru facturare recurentă cu risc de neplată, aceeași logică se poate aplica la fiecare ciclu, nu doar la prima tranzacție cu un client nou — proformă la fiecare scadență, factură fiscală doar după confirmarea încasării.

Cum se leagă modulul de facturare de restul ERP-ului

Facturarea nu funcționează izolat — depinde de date corecte din alte module și, la rândul ei, alimentează contabilitatea și rapoartele financiare.

Entitățile esențiale: contract, comandă, factură, plată

Un model de date minimal funcțional leagă patru entități: contractul sau comanda (sursa condițiilor comerciale), factura (documentul generat, cu starea ei — proformă, emisă, transmisă, plătită), plata (încasarea asociată, parțială sau integrală) și, pentru proiecte, etapa de execuție (procentul sau situația de lucrări care declanșează o factură parțială). Modulul de vânzări și comenzi intră în detaliu pe partea dinaintea acestui handoff — confirmarea comenzii, rezervarea de stoc și regulile de preț care ajung deja calculate în factură. Fiecare factură păstrează o referință explicită către sursa ei — comanda sau contractul — și către cursul de schimb folosit la emitere, ca istoricul să rămână auditabil oricând, nu doar la închiderea lunii curente.

Handoff-ul cu stocurile și livrarea

Pentru companii cu logistică fizică, facturarea depinde direct de confirmarea de livrare din modulul de gestiune a stocurilor sau din modulul WMS — de exemplu, AWB-ul confirmat de curier declanșează automat factura aferentă, în loc să aștepte introducerea manuală a stadiului de livrare. Fără acest handoff, riști fie să facturezi înainte ca marfa să ajungă efectiv la client, fie să întârzii facturarea cu zile după livrarea reală, ambele cu impact direct asupra cash-flow-ului.

Ce alimentează în aval: raportare și cash-flow

Odată emisă, factura devine sursă pentru rapoarte pe care alte module sau echipe le consumă direct: vechimea soldurilor — facturi restante pe intervale de întârziere —, previziunea de încasări pe săptămâni sau luni, și reconcilierea automată cu extrasul bancar la confirmarea plății. În paralel, aceeași factură generează automat nota contabilă corespunzătoare — mecanica exactă e tratată în modulul de contabilitate. Fără o legătură directă între modulul de facturare și aceste rapoarte, orice previziune de cash-flow devine un exercițiu manual, reconstruit din facturi exportate — exact tipul de muncă repetitivă pe care un ERP la comandă ar trebui să-l elimine.

Întrebări frecvente

Ce curs valutar trebuie să folosească factura, dacă contractul e în euro?

De regulă, ultimul curs de schimb comunicat de BNR — cel din ziua anterioară emiterii, valabil pentru ziua curentă —, cu excepția cazului în care contractul stabilește explicit un alt curs de decontare. Cursul folosit la emitere rămâne fix pentru acea factură, chiar dacă între timp cursul BNR variază.

Poți emite factură fiscală direct, fără proformă?

Da — proforma e opțională, nu obligatorie prin lege. E utilă mai ales pentru clienți noi sau tranzacții cu risc de neplată, unde vrei confirmarea plății înainte să declanșezi obligația de TVA. Pentru clienți existenți, cu istoric de plată bun, majoritatea companiilor facturează direct.

Cum se calculează procentul de facturare pe un proiect cu etape?

Cel mai des, pe baza procentului de servicii executate din total, sau pe baza proporției costurilor înregistrate față de costul total estimat. Alegerea metodei ține de tipul proiectului și trebuie stabilită explicit în contract, nu lăsată la interpretare la fiecare etapă.

Ce se întâmplă cu avansul, dacă proiectul se facturează pe etape?

Avansul se regularizează proporțional cu fiecare factură parțială emisă ulterior, până se epuizează — nu rămâne o sumă separată, ignorată până la finalul proiectului. Modulul de facturare trebuie să țină evidența automată a acestei consumări.

Facturarea recurentă funcționează și cu proforme, nu doar cu facturi fiscale?

Da — poți defini un ciclu recurent care generează proforme, util când vrei confirmarea plății la fiecare ciclu înainte de factura fiscală, exact ca la o tranzacție unică, doar repetată automat la intervalul stabilit.

Ce se întâmplă dacă un client renunță la abonament la jumătatea ciclului de facturare?

Ciclul recurent trebuie suspendat sau anulat fără să șteargă facturile deja emise — istoricul rămâne intact pentru contabilitate și pentru eventuale dispute ulterioare. Dacă anularea intervine în mijlocul unei perioade deja facturate, regularizarea se tratează separat, de regulă printr-o notă de credit, nu prin ștergerea facturii.

Un modul de facturare bine integrat nu se vede din exterior — se vede în lipsa erorilor: facturi corecte de prima dată, fără reconciliere manuală între comandă și document, fără curs de schimb greșit sau avans uitat. Dacă evaluezi ce ar trebui să acopere facturarea într-un ERP construit pentru fluxul tău specific, pornește de la ghidul complet al modulelor ERP sau răsfoiește toate modulele din acest hub.