Moldova e-Factura Requirements: B2B E-Invoicing Guide (2026)

Moldova e-Factura requirements center on the country's national electronic invoicing system operated by the Moldova State Tax Service (SFS) inside SIA Cabinetul personal al contribuabilului, the taxpayer cabinet. e-Factura launched as a voluntary service in 2014, became mandatory for B2G invoicing in 2023, and is scheduled to expand into mandatory B2B use from October 1, 2026. If your business issues invoices in Moldova, or trades with Moldovan entities, those dates matter because the system is moving from optional use to a standard part of invoice compliance.

Just as important, e-Factura is not a separate standalone website. It is a service embedded within SIA Cabinetul personal al contribuabilului, Moldova's unified electronic environment for interacting with the tax authority. In practice, that means businesses access the Moldova e-invoice system through the taxpayer cabinet rather than through an isolated e-invoicing portal, and the operational rules sit alongside broader fiscal and reporting workflows managed by the SFS.

This guide focuses on the operating reality: where the system lives, who must use it now, what is expected to change in 2026, and how the workflow functions in day-to-day finance and ERP environments.

If you just need the scope in one glance:

• Mandatory now: B2G suppliers issuing invoices to government entities
• Planned from October 1, 2026: broader B2B use for transactions between VAT-registered taxpayers

The Mandate Timeline: From Voluntary Service to Mandatory B2B

Moldova's mandatory e-invoicing 2026 rollout makes more sense when you view it as a phased tax-administration program rather than a sudden one-off compliance change. The system started as an optional digital invoicing service, then became compulsory in public procurement, and is now moving toward broader B2B use for VAT-registered businesses.

• 2014: Moldova launched e-Factura as a voluntary electronic invoicing service. At this stage, businesses could use it to issue tax invoices digitally, but paper and legacy workflows still remained common across the private sector.
• 2023: e-Factura became mandatory for suppliers selling to government entities. This B2G phase mainly affected companies participating in public procurement, where invoice issuance through the state system became part of doing business with the public sector.
• October 1, 2026: Under the announced national rollout, Moldova is expected to extend the requirement to B2B transactions between VAT-registered taxpayers. In practical terms, this is the major compliance change finance teams need to prepare for now: if both parties are VAT-registered, the invoice workflow is expected to move further into the e-Factura regime.

For most readers, the key scope point is simple: the 2026 rollout is framed as a broad B2B obligation for VAT-registered businesses rather than a narrow pilot or turnover-threshold program. Finance leaders should still monitor implementing guidance closely, because detailed scope, carve-outs, and onboarding mechanics can change as the mandate moves from policy roadmap to day-to-day enforcement.

According to the IMF's 2025 Article IV consultation with Moldova, Moldova's fiscal deficit is projected to widen to 4.8 percent of GDP in 2026, and the IMF said the country raises less tax revenue than peers through a complex and distortive tax system. That is the policy backdrop for tighter digital tax controls, including e-Factura. Moldova is also moving in the same broad direction as European e-invoicing reforms tied to ViDA (VAT in the Digital Age) and Peppol-style interoperability, even though its implementation is country-specific. If your group also invoices in Romania, compare Moldova's rollout separately against Romania's parallel RO e-Factura mandate rather than assuming the same workflow applies in both jurisdictions.

---

How e-Factura Works Inside the Taxpayer Cabinet

Since June 3, 2025, Moldova's electronic fiscal services have been accessed through a single environment: SIA Cabinetul personal al contribuabilului. The older servicii.fisc.md portal was retired as the main access point, so teams looking for Moldova taxpayer cabinet e-invoice functions now need to work inside the unified taxpayer cabinet rather than a separate legacy service page. For implementation planning, that change matters because user training, access control, and support documentation should all point to the cabinet as the operational entry point.

In practice, users first authenticate to the taxpayer cabinet with their approved digital credentials, then open the e-Factura service from the electronic services area. From there, Moldova SIA e-Factura operates as an always-available working environment for invoice tasks, which means finance teams can create, review, and submit invoice data without waiting for office-hour processing windows.

For implementation teams, the workflow is best understood as a short operating sequence:

1. Log in to the taxpayer cabinet with the organization's approved credentials.
2. Open the e-Factura service and choose the relevant path, such as creating an invoice directly in the interface or importing structured data.
3. Enter or upload invoice data and confirm that the required tax fields or XML structure are complete.
4. Submit the invoice for validation and processing through the state service.
5. Record the confirmation or status response so your AP, AR, or ERP process has evidence that the invoice was accepted or flagged for follow-up.

For foreign suppliers and multinational finance teams, the main challenge is not the logic of the workflow but the interface language. The taxpayer cabinet is primarily a Romanian-language environment, which can slow onboarding for English-speaking users who are seeing the portal for the first time after the migration. Even so, the underlying process will feel familiar to teams that have worked with other European clearance or reporting-style systems: complete the required fields, validate the structured payload, submit it through the state portal, and retain the resulting status evidence.

This is also why Moldova should not be treated as an isolated case. Other Eastern European jurisdictions use similar structured e-invoicing flows, even though each country has its own portal design, terminology, and format rules. If your team is already comparing regional models, it helps to review Latvia's structured e-invoicing requirements alongside Moldova's setup, because the user journey is different but the implementation mindset is often the same.

Role-Based Paths: Nonresidents, Transporters, and Buyers

One practical detail many English-language guides miss is that Moldova's e-Factura workflow is not a single generic screen for every user. Inside the taxpayer cabinet, the system uses role-based menus. A State Tax Service maintenance notice dated March 19, 2025 referred to separate interfaces for nonresident users, transporter users, and buyer users, which signals that access and daily tasks are organized by business role, not just by company name.

Any Moldova e-Factura guide that ignores these role splits will miss a real implementation issue:

• Nonresidents: Foreign suppliers dealing with Moldovan businesses may need a dedicated nonresident path rather than the domestic taxpayer flow. In practice, this is where a foreign entity may submit an electronic invoice, monitor whether it has been processed, or confirm its current status. The main operational risk is onboarding, because registration, identification, and taxpayer-cabinet credentials can become a go-live blocker if left too late.
• Transporters: This path is built around transport-document activity, including the ability to search transport documents. It matters when goods movement has to be aligned with invoice activity. If your organization works with third-party logistics providers, decide early whether the transporter, the supplier, or both will be responsible for checking document status in this interface.
• Buyers: This is the path most Moldovan AP teams will use day to day. It is where receiving businesses review incoming e-invoices, accept them where the workflow requires it, and flag exceptions when invoice data does not match the purchase order, goods receipt, or contract terms.

One legal entity may need more than one operating path. A company can be a buyer in one transaction, a supplier in another, and in some cases coordinate with transport participants as well. That affects ERP integration design, user provisioning, and staff training. Role mapping should be part of the project plan from the start, much like teams preparing for Croatia's upcoming B2B e-invoicing mandate need to map regulatory obligations to actual system users and approval flows.

---

System Integration: The PostInvoice API and XML Workflows

For teams evaluating Moldova e-Factura API connectivity, the main distinction is simple: invoices can be entered manually in the taxpayer cabinet, or they can be submitted programmatically through the API layer. That second path matters for ERP projects because it lets finance and IT teams push invoice data directly from accounting, billing, or order management systems into e-Factura without rekeying each document in the web portal.

The technical model is built around structured XML exchange. In practice, that means the invoice payload is not a free-form upload. It must match Moldova's e-Factura schema and include the core data points the system expects to validate, such as supplier and buyer tax identification numbers, invoice totals, VAT values, and line-item detail. If the XML structure or required fields do not align with the schema, the submission workflow becomes an exception-handling problem rather than a straight-through process.

In practical terms, there are three different levels of interaction to distinguish: manual portal entry by a user inside the taxpayer cabinet, XML import into the e-Factura environment, and true system-to-system submission from an accounting or ERP platform. Official guides and notices confirm the API and XML handling model; the exact submission path your team uses depends on how much automation your internal systems can support.

The published SIA e-Factura integration guide shows that the API is designed for external accounting systems and supports programmatic submission, invoice search, and status checks. Separately, a March 19, 2025 maintenance notice referenced API adjustments for XML import and the PostInvoice workflow for nonresident, buyer, and transporter use cases. The consistent takeaway is that the state platform is meant to support machine-to-machine invoice handling, not just browser-based data entry.

That matters for transport-heavy operations too. The same integration surface is tied to document-search and status-tracking functions that help reconcile goods movement with invoice activity. Where invoicing and shipment control are closely linked, those lookup capabilities can become part of a broader validation flow between warehouse, transport, and finance systems.

From an operational standpoint, the right integration choice depends on volume and system maturity. Manual entry through the taxpayer cabinet may be workable for low document counts or early-stage compliance setups. But once invoice volumes rise, API submission usually becomes the more sustainable model because it removes repetitive portal entry, reduces transcription risk, and supports tighter controls between the ERP and Moldova e-Factura workflow. For implementation leads, the real question is not whether the interface exists, but whether internal data quality and XML mapping are strong enough to support reliable automated submission.

Preparing for October 2026: What Finance Teams Should Do Now

From now to 1 October 2026, treat Moldova e-invoicing requirements as an implementation project, not just a tax update. The teams that struggle with Moldova electronic invoice requirements are usually not the ones who missed the headline, but the ones who left role design, portal access, testing, and ERP mapping until the last minute.

Do not assume non-compliance will be handled informally. Under Article 260(4) of Moldova's Tax Code, failure to present a tax invoice within the deadlines set by Articles 117 and 1171 is punishable by a fine of 3,000 to 3,600 lei per invoice, capped at 72,000 lei for invoices not presented on time. In practice, the penalty framework is enforced by the State Tax Service, so finance leaders should confirm the exact article and scenario that applies to their transaction mix before go-live.

A practical readiness checklist looks like this:

1. Audit your current invoice flows and isolate which domestic B2B transactions may need to move through e-Factura under the announced 1 October 2026 rollout.
2. Verify access to the taxpayer cabinet and confirm who in your organization can create, sign, send, receive, accept, reject, or correct invoices inside the system.
3. Decide which role paths apply to you, supplier, buyer, or both, and document exceptions such as nonresident or transport-related workflows.
4. Measure invoice volume honestly. If your team issues invoices in meaningful daily volume, manual portal work may not scale well.
5. Run live workflow tests before the deadline, including draft creation, submission, buyer-side handling, corrections, and exception cases.
6. Train both AR and AP staff on the actual taxpayer-cabinet sequence so the process does not depend on one specialist.

There is also a downstream operations issue many teams miss. As Moldova e-invoicing requirements push more invoice traffic into structured electronic workflows, the bottleneck shifts from data entry to validation, mapping, and routing. Finance teams still need to reconcile supplier data, totals, VAT fields, and line items, then move that information into accounting or ERP systems in a usable format. For businesses handling mixed invoice flows, especially where Moldovan suppliers also send PDFs, JPGs, or PNGs, tools that extract and structure data from Moldovan invoices can help standardize invoice-level and line-item data into XLSX, CSV, or JSON, preserve source file and page references, and reduce manual rekeying.

If you are a smaller local business with low invoice volume, a portal-first process may be enough at the start, provided you sort out cabinet access, user roles, and basic testing well before go-live. If you are handling higher volumes, multiple entities, nonresident transactions, or ERP-driven billing, the priority shifts toward API mapping, role design, and end-to-end testing before the deadline.

For Moldova specifically, the main operational risk is not only the legal deadline. It is arriving at October 1, 2026 without taxpayer-cabinet access, role assignments, and a tested submission path for the invoice volumes your team actually handles.