Romania e-Factura Compliance

Every B2B and B2G sales invoice issued from a Romanian subsidiary has to exist as a structured XML document that has passed through ANAF's Spatiul Privat Virtual before it counts as issued. NetSuite prints a clean PDF and posts a clean GL entry. It does not build RO_CIUS UBL, it does not hold an OAuth token against the SPV, and it has no idea what an upload index is. So the work lands on a person: export the invoice, rekey it into a converter or the portal, upload the XML, paste the returned index into a memo field, then come back the next day to find out whether it was accepted or rejected for a missing CUI, an unmapped unit of measure, or a rounding difference of one ban. At low volume that is tedious. At real volume it fails silently, because an invoice that was never uploaded looks exactly like one that was.

What ECOSIRE builds

ECOSIRE builds this app for you. Nothing here is a shrink-wrapped download, and there is no trial edition sitting on a server waiting for a credit card. After a scoping call we quote a fixed price, then we build the customisation against your chart of accounts, your item catalogue, your subsidiary structure and your nexus setup, deploy it to your sandbox, and move it to production once your finance team has signed off on real documents.

The build is native NetSuite work. SuiteScript 2.1 does the heavy lifting: User Event scripts for validation, Map/Reduce for batch generation, Scheduled scripts for status polling, Suitelets for the operator screens and a RESTlet where you need to trigger a run from outside. SuiteFlow handles the approval and resubmission paths. Configuration, code lists and the full call log live in custom records. Everything is delivered as an SDF project and installed as an unmanaged bundle that you own outright. No middleware of ours sits between your account and ANAF, and no invoice data is copied into an ECOSIRE-hosted database.

The submission pipeline

A Map/Reduce script sweeps a saved search of transactions that are approved, posted, belong to the Romanian subsidiary and carry no e-Factura state, and hands each one to a builder module that produces the RO_CIUS UBL 2.1 payload. The payload is written to a dedicated File Cabinet folder and linked to the transaction, so the exact bytes that were sent are always retrievable years later.

Authentication to the SPV endpoints uses OAuth 2.0 with your qualified certificate. Access and refresh tokens live in a protected custom record readable only by the integration role, never in a script parameter and never in a note field. Upload returns an index, which is stamped onto a custom transaction body field with a timestamp. A Scheduled script polls the status endpoint on the interval you choose, downloads the response archive once the state resolves, extracts the ANAF-signed XML into the File Cabinet, and writes the final state back to the transaction.

Rejections are parsed into readable error text on a child custom record, so an AR clerk sees exactly which element ANAF objected to, corrects it on the NetSuite record, and resubmits from a button on the transaction instead of from a browser tab. Every request body, response body and HTTP status is written to an audit custom record with a retention policy you control.

Mapping your NetSuite data to RO_CIUS

Most e-Factura failures are data failures, not integration failures. The build therefore starts with a mapping pass over your own records: customer CUI and trade register number on the Customer record, the invoice type code, translation from your NetSuite units of measure to the standard code list, tax category and exemption reason per tax code, payment means, and the extra fields that intra-community supplies and reverse-charge scenarios require. Where a value has no home in your account we add a custom field or a custom list rather than overloading a memo.

A User Event script validates the complete set on save, so a document that ANAF would reject is blocked in NetSuite by a message naming the exact field. Saved searches ship with the build: unsubmitted invoices past your internal cut-off, rejected invoices awaiting correction, submitted invoices with no signed file returned, and a subsidiary-level daily reconciliation between posted revenue and accepted documents.

Inbound documents and the purchase side

If your scope includes supplier documents, a second pipeline lists the messages available to your CUI, downloads each archive, parses the UBL into a staged custom record, and matches it against open Purchase Orders and Item Receipts by supplier CUI, document number and total. Matched documents can be converted into Vendor Bills with the source XML permanently attached; unmatched ones queue on a Suitelet worklist for AP review. This half is optional and priced separately at quotation, because for many finance teams the outbound obligation is the entire problem.

Who this is for

Romanian entities running NetSuite standalone, and OneWorld groups where Romania is one subsidiary among several and nobody wants a country-specific process bolted onto the group close. It suits shared service centres that raise invoices for Romania from another country, and controllers who need a single NetSuite screen that answers whether every invoice issued this month is accepted, pending or rejected.

How delivery works

1. Scoping call. We walk your invoice types, subsidiary and nexus setup, tax codes, item catalogue and volumes, and confirm with you and your tax advisors which documents are in scope. 2. Fixed quote. You receive a written scope with the record-by-record mapping, the optional inbound module priced separately, and a delivery date. Nothing is built until you accept it. 3. Build. We develop against a sandbox refresh of your account, using your real master data shapes rather than a demo company. 4. Install in test. The bundle goes into your sandbox first. Your team issues real documents against the ANAF test environment and signs off. 5. Production. We install into production during a window you pick, migrate configuration, and stand by for the first live submission cycle. 6. Support window. A defined post-go-live support period is included in the quote, covering defects, code-list updates and hand-holding through your first month-end.

What we do not claim

This is a build, not a download. There is no free trial, because nothing exists for your account until we make it. We are not a certified partner of any software vendor and we do not resell anyone else's connector; we write NetSuite code that you keep. We do not give tax advice: your accountants confirm which documents are in scope, which deadlines apply and how transactions should be classified, and we implement that faithfully. Regulatory detail changes, so code lists, deadlines and endpoints are configuration records rather than constants in the source, and structural changes are handled under a support or change agreement.