e-Factura (ANAF) and eMAG: where MEGZO fits, and where it does not
Every seller who calls us asks some version of the same question: "does your integration do e-Factura?" The honest answer is no, and that no is deliberate. MEGZO never generates a fiscal invoice and never talks to ANAF. What it does is narrower and, frankly, safer: it picks up the invoice PDF your ERP already produced and attaches it to the matching eMAG order. This guide draws that line clearly, because confusing the two is how sellers end up with duplicate fiscal documents, mismatched numbers, or compliance gaps nobody owns.
What e-Factura actually is
e-Factura is Romania's mandatory electronic invoicing system, run by ANAF. A fiscal invoice is a legal document with a sequential number, a VAT breakdown, and a defined issuer. Generating one and submitting it to the ANAF SPV is an accounting and tax act. It belongs to whoever owns your books — your ERP, your invoicing software, your accountant. Get the issuer wrong and you have a real legal problem, not a sync hiccup.
That is exactly why MEGZO stays out of it. We are a data processor moving order and stock data between systems. We are not your accounting system, and we should not be the thing that decides what a fiscal invoice says.
Where MEGZO actually sits
MEGZO keeps your ERP — Acumatica in the live Romanian reference, though the design is connector-agnostic — as the single source of truth. It is a config-driven sync layer, not a hub that owns your data the way BaseLinker does. The split looks like this:
- Your ERP + ANAF create the fiscal invoice and handle e-Factura. MEGZO does not see, alter, or trigger that step.
- MEGZO fetches the already-produced invoice PDF (for example, an Acumatica file attachment) and uploads it to the eMAG order via the order/attachments endpoint. The PDF arrives exactly as your ERP made it.
So the invoice attached to an eMAG order is a copy of a document that already exists. MEGZO never mints invoice numbers, never computes VAT, never builds the e-Factura XML, never submits anything to the SPV.
Why this separation is the correct design
Fiscal correctness has to live in one place. If a middleware tool also generated invoices, you would have two systems that both think they own invoice numbering and VAT — a guaranteed reconciliation nightmare. Keeping generation in the ERP means there is exactly one authoritative record, and MEGZO just carries a copy to the channel.
It also matches how MEGZO treats everything else. Orders are idempotent: one eMAG order becomes exactly one ERP Sales Order, enforced by a unique order link, a per-order lock, and an ERP-side duplicate pre-check, so retries never double-post. Stock uses oversell protection — channel stock is max(0, available − buffer) with a configurable buffer (the live RO seller runs a buffer of 2), continuously reconciled. The discipline is the same on invoices: don't create, don't guess, carry the authoritative artifact and attach it.
What this means in practice
On a normal eMAG order, the sequence runs like this: the order lands and becomes one Acumatica Sales Order; you (or your ERP automation) produce and, where required, e-Factura the fiscal invoice through ANAF; MEGZO then fetches that PDF and attaches it to the eMAG order. AWB handover finalises the order via eMAG's awb/save. The whole loop runs on a 5-minute pull heartbeat plus webhook wake-ups where the channel supports them.
If you have not produced an invoice yet, there is nothing for MEGZO to attach — and that is the correct behaviour, not a bug. The integration will not invent a fiscal document to fill the gap.
The short version
MEGZO does not do e-Factura. Your ERP and ANAF do. MEGZO fetches the finished invoice PDF and attaches it to the eMAG order, idempotently, with the same care it applies to orders and stock. If a vendor tells you their connector "does e-Factura," ask them who owns the invoice number — because in a correct design, it is never the integration layer.
See all integrations, browse the guides, or get started.