A useful RO e-Factura integration must let the finance team trace an invoice from its source record through submission, processing and the relevant downloaded response. Generating XML is one task. The larger software buying decision is whether staff can identify what happened, resolve exceptions and prove which records belong together.
This guide covers business integration design for a Romanian company connecting invoicing or ERP software to ANAF services. It does not set tax treatment, filing deadlines or the legal scope of invoicing obligations. Assign those decisions to your accountant or responsible adviser. TuniCyberLabs serves buyers remotely and can scope the application, integration and handover work around the requirements those owners approve.
The official API separates stages for a reason
ANAF publishes separate service methods for XML upload, message status, available responses and response download, with test and production endpoints. This gives a buyer a practical acceptance question: which of these stages does the proposed connector implement and expose to staff?
The official OAuth integration procedure describes application registration, authorised access and tokens. It also explains that an HTTP 200 response can accompany service-level success or error information. A green HTTP response indicator is therefore not a sufficient business status.
Ask the developer to confirm the current documented endpoint and authentication configuration during implementation. Avoid a project estimate based on an old code sample without checking its assumptions against the services the organisation will actually use.
Give every invoice a traceable history
Start with a fictional distributor whose ERP creates invoices and whose finance team currently checks outcomes manually. The integration should preserve the relationship between the source invoice, the generated document version, submission attempts, returned identifiers and downloaded responses.
Agree an internal state model with finance staff. It might distinguish prepared, awaiting submission, submitted with a known reference, awaiting processing, response available and requiring correction or investigation. These are suggested application labels, not a claim that ANAF uses the same names. Map them explicitly to the documented response meanings.
Do not overwrite an earlier attempt when a correction is made. Keep the document version and response associated with that attempt so the reviewer can understand the sequence. Let the finance owner decide what constitutes an authorised correction in the business process.
Design the exception queue before the dashboard
An attractive count of submitted invoices is less useful than a clear list of items requiring attention. Give each exception a reason, owner, age and next permitted action. Distinguish a document validation issue from an access problem or an unavailable remote service; they need different people to resolve them.
A useful review screen should answer:
- ▸Which legal entity and source invoice does this item belong to?
- ▸Which document version was submitted, and when?
- ▸What reference or response was received?
- ▸Is the outcome known, pending or still uncertain?
- ▸What action can the authorised user take, and who has already acted?
Keep response details available without exposing credentials or unrelated customer records. Use clear Romanian labels for the finance users when required, while retaining the underlying response information needed by support. Decide how internal terminology maps to the accountant's workflow before translating the interface.
Handle retries without guessing the business outcome
Test the case where the connection is lost during submission. The application may not yet know whether the remote service received the document. A retry rule must account for that uncertainty and the documented API behaviour; do not invent an idempotency guarantee that the provider has not made.
Separate status checks and response retrieval from submission attempts. Record enough context to investigate the existing attempt before staff choose another action. Make automatic retries bounded and observable, and respect the provider's current access limits.
Also rehearse a delayed response, a validation error and a temporary authorisation failure. Show what the finance team sees in each case. These examples turn “error handling included” into an acceptance requirement that can be demonstrated.
Make access continuity part of handover
The buyer should know who owns application registration, which authorised people are involved and how access is maintained when responsibilities change. ANAF's OAuth documentation makes clear that user rights and application access both matter. Do not treat a developer's temporary successful connection as a complete operational arrangement.
Require secure handling of tokens and application credentials. Keep secrets out of screenshots, support tickets and ordinary logs. Document the renewal or replacement procedure using the current provider instructions, then test how the application behaves when access is unavailable. The organisation needs a named owner for restoring access.
Keep test and production configuration distinct. A test should not submit real business documents to production by accident. Use appropriate fixtures and agree who authorises the move to live operation, including the initial document checks by finance staff.
Reconcile the integration with the ERP
Define a repeatable comparison between relevant source invoices, submission records and downloaded outcomes. It should find missing links and unresolved items, not simply count successful network calls. Have finance specify the reporting window, exceptions and review schedule that fit its process.
For example, an invoice present in the ERP but absent from the integration queue needs a different investigation from a submitted item awaiting a response. A downloaded response without a matched source record needs another. Keep these categories visible so a developer can fix the underlying mapping or scheduling defect.
Choose retention and access arrangements with the responsible business owners. Preserve the records they require and make retrieval practical. A directory of unlabelled files is difficult to use when someone needs to reconstruct one invoice's history.
Ask for an acceptance pack the receiving team can use
Request an approved mapping specification, representative test cases, a state diagram, exception procedures and an operational handover. Include a demonstration led by the receiving finance and support staff. They should be able to find an invoice, explain its current state and identify the next authorised step.
If this work forms part of a wider ERP replacement, read our guide to software modernisation and handover for Romanian organisations. Use the software vendor scorecard to compare what competing proposals actually deliver.
Explore our software engineering services and request an e-Factura integration scope review. Bring an approved sample workflow, the current ERP boundary and the unresolved states your staff need to manage.