DGII grants a 6-month extension for electronic invoicing: what changes and what doesn't
The extension: what was actually announced
The Dominican Republic’s tax authority (Dirección General de Impuestos Internos — DGII) announced a six-month extension to the mandatory implementation deadlines for the Electronic Tax Receipt (e-CF) for the Medium and Small taxpayer segments. The mandate isn’t gone — the finish line just moved.
TL;DR: More time to implement, not more time to ignore. Companies already in production keep their competitive advantage. Those that aren’t get a margin to do it properly — not to postpone it another half-year.
Law 32-23 still stands. The architecture, the XML schemas, the XAdES signature, the acknowledgements (ACECF), and the full validation cycle with DGII all remain unchanged. The only thing that moved is the calendar.
Who does this really affect?
The extension touches two categories:
- Medium Taxpayers — whose original deadline was nearly upon them; it now slides six months.
- Small Taxpayers and SMEs — the largest segment, where the technology gap was widest.
Who does NOT benefit:
- Large Taxpayers — already in production since 2024. No going back for them.
- Public sector and state suppliers — bound by the deadlines in their existing contracts.
If your company is classified as a Medium or Small taxpayer, you technically have six extra months. But that’s the shallowest reading of the news.
Why the extension exists (and why it shouldn’t make you complacent)
We’ve spoken directly with several taxpayers over the past few months. The most common obstacles were:
- Accounting software without an e-CF module — legacy systems where the vendor hadn’t shipped the update yet.
- Digital certificates — confusion around issuance, custody, and renewal of the signing certificate.
- TesteCF testing — teams without the experience to validate the full cycle against the sandbox.
- ERP integration — SAP, Oracle, Odoo, Microsoft Dynamics: each one its own path to DGII.
The extension acknowledges this. But there’s something subtler: the good vendors are saturated. Every extension pushes demand for serious implementers into the next window. If you leave everything to the last month, you’ll compete for calendar slots with the rest of the country.
What changes technically
Nothing. And that’s exactly the point.
- e-CF XML structure: unchanged. The official DGII-published schema still rules.
- Digital signature: still XAdES-BES over the full XML, with a certificate issued by authorized providers (Avansi, Camara TIC, etc.).
- Endpoints: the SOAP/REST services for submission, status queries, and acknowledgement retrieval are stable.
- Document types: Consumer Invoice (31, 32), Tax Credit (32), Debit Notes (33), Credit Notes (34), Purchases (43), Minor Expenses (44), Government (45), Exports (46), Summary (47) — no changes.
- Operational deadlines: the daily RFCE (Summary Receipt) is still due in the first hours of the next day. ACECF still has to be processed near real-time.
If you’ve already invested in a correct integration, don’t touch anything. The extension isn’t an invitation to wait for another version of the protocol.
How to use the 6 months (in order)
If you’re starting now, this is the route we recommend based on what we learned implementing this system for clients in banking, retail, and manufacturing:
Month 1 — Discovery
- Exhaustive list of the document types you issue today.
- Map each one to the corresponding e-CF type.
- Identify flows where invoicing isn’t a single event — partial payments, returns, notes, exports, multi-currency.
Month 2 — Platform decision
Three real options:
| Option | Cost | Time | Control |
|---|---|---|---|
| Buy your current ERP’s module | Medium | 1–3 months | Low |
| Hire a certified third-party API | Low recurring | 2–4 weeks | Medium |
| Build your own integration | High up-front | 3–6 months | Total |
There’s no universal answer. A 5-store distributor should hire an API. A financial group with 14 internal systems likely needs API + custom integration.
Month 3 — Digital certificate and sandbox
- Request the certificate before you start integrating.
- Renewals take time too: if your certificate expires mid-implementation, that’s a planned risk.
- Provision your access to TesteCF.
Month 4 — Integration and end-to-end testing
- Issue every document type you’ll use.
- Validate acknowledgements, voids, modifications, daily summaries.
- Test error scenarios: rejections, timeouts, expired certificates.
Month 5 — Controlled pilot
- Move to production with a subset: one branch, one customer type, limited hours.
- Measure rejection rate, average latency, cases where the cashier abandoned the transaction.
Month 6 — Full rollout and monitoring
- Expansion to every branch.
- Real observability: success-rate dashboards, alerts on consecutive rejections, structured logging.
The lesson nobody publishes
The technical side of e-CF is solvable. The hard part is operational:
- Train the cashier staff to know what to do when a document is rejected in real time.
- Rethink the accounting flows because you no longer “post” at month-end — every e-CF is an immediate transaction.
- Rewrite return procedures, because a Credit Note now travels through DGII before the customer gets their refund.
The extension gives you time to do this right. Not to leave it for the last month.
If you find yourself on the wrong side of the calendar
We’ve worked with companies that arrived three weeks from the cutoff without a plan. It’s stressful but salvageable. The difference between “stressful” and “catastrophic” is always the same: they started calling us when they saw the date, not after it had passed.
If your team is weighing options — from a certified API to your own ERP integration — let’s talk. We’ll tell you honestly whether you need to speak with us, with your current software vendor, or directly with DGII.
The extension is a gift. Treat it as a schedule, not as permission.
