Romania e-Factura Reporting

The problem

Romania's RO e-Factura mandate covers B2B and B2G invoicing, and it is not a print job. Each invoice has to be rendered in the required XML structure, uploaded to ANAF, and then followed — because the upload returns an index, not a verdict. The verdict arrives later, and it can be an acceptance, a validation rejection, or nothing at all if the upload never landed.

SAP Business One has no concept of any of this. It posts the A/R Invoice and the Journal Entry correctly and stops there. Which means somebody in finance ends up owning a spreadsheet of upload indexes, polling a portal by hand, and trying to reconcile which of last week's 200 invoices actually cleared. The failure mode is quiet: an invoice looks fine in SAP B1, sits in the aging report, gets chased for payment — and was rejected by ANAF eleven days ago for a missing buyer tax code that nobody looked at.

That asynchronous gap between uploaded and accepted is the entire problem, and it is exactly what native SAP B1 cannot express.

What ECOSIRE builds

We build a per-tenant SAP Business One add-on that generates, uploads, polls and reconciles RO e-Factura submissions, using SAP's supported extensibility surfaces only.

Document generation

A/R Invoices and A/R Credit Memos are read through the Service Layer (Invoices, CreditNotes) and mapped to the RO e-Factura XML structure. The mapping is explicit and delivered as a written specification you can audit: Business Partner identification (CUI/CIF, registration data, addresses), header fields, line-level item codes and unit of measure, quantities, net amounts, discount treatment, and the VAT breakdown built from the document's SAP B1 tax codes so the XML totals reconcile to the posted Journal Entry. Fields with no native home get a UDF on the correct object — OINV, ORIN, OCRD — driven by a formatted search or validated value list rather than free text.

Upload and the index

Upload is handled by the add-on service. The returned upload index is immediately persisted to a UDO submission record alongside the source document key, the generated payload, the timestamp and the current state. Nothing is transient; if the process is killed mid-run, the index is already durable and the poller will pick it up.

Status polling — the part that matters

A scheduled poller walks every submission that is not yet in a terminal state, queries ANAF for the outcome against its stored index, and transitions the record. On acceptance, the returned identifier and the signed response are written back to locked UDFs on the source invoice and archived on the submission record. On rejection, the validation errors are parsed into readable reasons and the invoice is flagged for correction. Polling is idempotent and rate-aware — the same index is never double-claimed, and a document already in a terminal state is never re-uploaded by accident.

Reconciliation you can actually read

A Crystal Report shows, for any date range: invoices posted, invoices uploaded, uploads accepted, uploads rejected with reason, and — the important one — invoices posted but never uploaded. That last bucket is where compliance gaps hide, and it is the first thing a finance manager should be able to see. Drill-through takes you straight to the offending A/R Invoice.

Controls before the document leaves

Pre-upload validation runs the same rules as the schema: Business Partner tax identification present and well-formed, every line carrying a tax code, currency and rounding consistency, numbering series integrity, and the B2G-specific fields where the recipient is a public institution. Failures surface before upload rather than as a rejection days later. Where you want a human gate, the add-on hooks into standard approval procedures so flagged invoices need sign-off before transmission.

Credit memos and corrections

A/R Credit Memos are generated and uploaded in the same flow, with the reference to the corrected invoice resolved from the SAP B1 base-document link so nobody types an identifier by hand.

Who this is for

Companies running SAP Business One with a Romanian legal entity issuing B2B or B2G invoices — distributors, manufacturers, construction and services businesses, and any supplier to Romanian public institutions. It also fits multi-country groups where the Romanian company is one database among several and the group wants Romania handled inside SAP B1 rather than in a parallel tool.

If you issue a handful of invoices a month and are content to upload them manually, this will not pay for itself. The value is in volume, in the polling loop, and in never again discovering a silent rejection at month end.

Technical framing

Built as a SAP Business One add-on and integration layer on the Service Layer (REST) for document read and UDF write-back, the DI API where a transaction demands it, and UDO/UDF/UDT for the submission ledger, poller state and configuration. Compatible with SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or cloud-hosted. Endpoints, credential references, in-scope numbering series, polling interval and approval thresholds live in a setup UDT, so moving between test and production is a configuration change rather than a rebuild.

How delivery works

Nothing is pre-built and there is no instant download. Each deployment is built for your company database and your document flow.

1. Scoping call. We walk your invoice types, numbering series, tax codes, Business Partner master data quality, B2G exposure and correction process, and we identify what is missing for the schema before quoting. 2. Fixed quote. Written scope, fixed price, no hourly drift. 3. Build. Typical lead time is one working week from signed scope, depending on document types in scope and master-data remediation. 4. Install into your test company. Installed into the test database first and exercised with your own real documents end to end — including a deliberate rejection and a credit memo — so you see the failure path, not just the happy path. 5. Install into production. After test sign-off, installed into the production company database with a supervised first upload and polling window. 6. Support. A support window follows go-live for defect fixes and adjustments arising from real use.

You own the deployment. Source is delivered with it, documented, and maintainable by your own team or your SAP B1 partner.