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. Since 1 January 2021 it has been mandatory for taxable supplies made under public procurement, and it is mandatory for any business the SFS names on its list of compulsory e-invoice users. A general B2B mandate, widely reported for October 1, 2026, has not been enacted: as of October 2026, no Moldovan law or SFS order makes e-Factura compulsory for all VAT payers. Whether your business must use it therefore depends on two questions: do you supply under public procurement, and are you on the SFS list? Everyone else may use it voluntarily.
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, where the B2B mandate stands, and how the workflow functions in day-to-day finance and ERP environments.
If you just need the scope in one glance:
- Mandatory since 1 January 2021: taxable supplies under public procurement
- Mandatory for listed taxpayers: businesses on the SFS list of compulsory e-invoice users (74 companies after the March 2026 update)
- Not mandatory as of October 2026: B2B invoicing between other VAT payers, which stays voluntary; the reported October 1, 2026 mandate has no legal act behind it
The Mandate Timeline: Who Must Use e-Factura Now
Moldova's e-invoicing obligations have grown in steps, each set by a specific provision of the Tax Code or an SFS order. The date most English-language guides repeat is not one of them. In 2025 VATcalc reported that Moldova's Ministry of Finance confirmed a schedule running from technical documentation in H2 2025 to a January 2026 pilot and a full B2B mandate on October 1, 2026, and compliance vendors carried that date forward. No law, government decision or SFS order bringing in that mandate has followed.
- 2014: Moldova launched e-Factura as a voluntary electronic invoicing service. Businesses could issue tax invoices digitally, but paper and legacy workflows remained common across the private sector.
- 2019: the SFS approved its list of businesses obliged to use e-Factura (Order No. 124 of 15 March 2019). Under Article 117(1¹) of the Tax Code, a taxpayer on the list must present an electronic tax invoice to the buyer for its taxable supplies within Moldova. The list targets selected businesses, not a sector or a turnover band.
- 1 January 2021: under Article 117(1²), taxable supplies made under public procurement must be documented with e-Factura. Supplies of electricity, thermal energy, natural gas, electronic communications and communal services are excluded. For contract-level detail, see how e-Factura connects to Moldova's public procurement system.
- 2025 to 2026: the SFS keeps amending the list. Order No. 489 of 6 October 2025 added ten companies from 13 October 2025, and Order No. 141/2026, published on 20 March 2026, added seven and removed eleven, leaving 74 businesses on the list.
- February to March 2026: the Ministry of Finance consulted on a draft law on the e-Factura information system. It centres on public spending: alignment with the European standard EN 16931 and interoperability with the e-Achiziții procurement system. The law is designed to enter into force on the date of Moldova's accession to the EU.
- October 1, 2026: the reported B2B date passed without a legal act making e-Factura compulsory for all VAT payers.
For a finance team, the practical check is short. Find out whether any of your sales are made under public procurement contracts, and whether your company appears on the list published on the SFS website under "Utilizatori SIA e-Factura". The list can be amended at any time, and an amending order takes effect from the date it sets, so it is worth checking after each change. Beyond that, watch the e-Factura draft law and any Tax Code amendment to Article 117: a broader mandate would arrive through one of them, not through a vendor's announcement.
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 and the parallel rollout of Moldova's virtual cash register and electronic receipt regime. 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 rules 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 now access e-invoice functions through 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:
- Log in to the taxpayer cabinet with the organization's approved credentials.
- Open the e-Factura service and choose the relevant path, such as creating an invoice directly in the interface or importing structured data.
- Enter or upload invoice data and confirm that the required tax fields or XML structure are complete.
- Submit the invoice for validation and processing through the state service.
- 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.
If your team is already comparing regional models, review Latvia's structured e-invoicing requirements separately; the implementation mindset is similar, but portal design and format rules differ.
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 AP teams use when they receive e-invoices. 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, imported as structured XML, or submitted programmatically from an accounting or ERP platform. The system-to-system path matters for ERP projects because it lets finance and IT teams push invoice data directly 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.
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 e-Factura: What Finance Teams Should Do Now
Whether the obligation reaches you through a procurement contract or a place on the SFS list, 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:
- Check whether you supply under public procurement or appear on the SFS list, then map which of your invoice flows that obligation covers. A listed taxpayer must issue e-Factura for its taxable supplies within Moldova, not only for selected customers.
- 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.
- Decide which role paths apply to you, supplier, buyer, or both, and document exceptions such as nonresident or transport-related workflows.
- Measure your invoice volume. If your team issues invoices in meaningful daily volume, manual portal work may not scale well.
- Run live workflow tests before go-live, including draft creation, submission, buyer-side handling, corrections, and exception cases.
- 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 more of your invoice traffic moves 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 obligation applies.
For Moldova specifically, the main operational risk is being named on the SFS list or winning a procurement contract without taxpayer-cabinet access, role assignments, and a tested submission path for the invoice volumes your team actually handles.