Contingency and backup plans

Mosce ERP automatically handles loss of connectivity with DGII (the Loss of Connectivity mode): your e-CFs are signed locally, queued, and delivered to DGII within the regulated 72-hour window - the Printed Representation includes the mandatory notice that DGII defines for this mode. Mosce ERP does not issue paper Serie B vouchers during a technical incapacity episode (the Technical Incapacity mode): when the platform itself cannot generate or sign an e-CF, the taxpayer issues Serie B vouchers outside the platform using their authorized pre-printed stationery (DGII allows up to 15 calendar days for this backup). When normal service is restored, Mosce ERP records the paper numbers issued during the episode and emits the replacement e-CFs that reference them in <InformacionDeReferencia> within the regulated 30-day window.

Reading time: ~12 min

When to use this

• DGII is not responding and you want to know if you need to take action (short answer: almost never; Mosce ERP handles it).
• The system has entered Contingency Mode and you want to understand what it does and what you need to do.
• Your digital certificate has expired or the signing infrastructure has failed and you need to keep operating while it is restored.
• You need to explain to your accountant or a client how the regulated e-invoicing backup plans work.
• You are undergoing a DGII audit and need to document the traceability of e-CFs emitted during a contingency episode.

Before you start

• You have Fiscal Configuration complete and at least one active sequence for each e-CF type you plan to emit. See Fiscal configuration and e-CF sequences.
• Your role includes fiscal:read (read contingency status) and fiscal:manage (manual actions). To declare episodes from within Mosce ERP you also need fiscal:contingency:declare. To make decisions on overdue documents, fiscal:past-sla:decide. To emit replacements, fiscal:replacement:create. OWNER and ADMIN bypass all these checks.
• You have access to DGII's Virtual Office (OFV) with your digital certificate - the formal declaration is still made in the OFV, and the ID the OFV returns is what you register in Mosce ERP.
• You maintain a pre-printed Serie B stationery stock (authorized paper booklet) at the branch. This is the taxpayer's responsibility - Mosce ERP does not generate or store those sequences. DGII allows up to 15 calendar days of Serie B operation during a Technical Incapacity.

What counts as contingency

Per DGII Instructivo de Contingencia FE - Estado de Contingencia (February 2026, pages 3-4): "Electronic issuers are considered to be in a contingency state when they cannot emit and/or send e-CFs to DGII" - due to loss of connectivity or technical incapacity to emit them.

DGII defines two mutually exclusive contingency modes. Mosce ERP maps each one to a distinct behavior:

Per DGII Informe Técnico e-CF v1.0 §19 (Contingency Operation, March 2026, pages 48-50): "an electronic issuer is in a contingency state when situations arise that prevent the emission and/or sending of Electronic Tax Vouchers (e-CF) to the Dirección General de Impuestos Internos (DGII)".

There is also a third situation, DGII Contingency, which is triggered when DGII's own systems are unavailable. If it lasts more than 15 business days, DGII enables report submission (Books 606, 607, 608 and others) through the OFV and the taxpayer temporarily operates with non-electronic vouchers.

Mode 1 - Loss of Connectivity (handled by Mosce ERP)

Per DGII Informe Técnico e-CF v1.0 §19.1: "This applies when the electronic issuer has the capacity to generate the e-CFs, but cannot send them to DGII for real-time validation due to interruptions or intermittency in connectivity services."

This mode is fully covered by Mosce ERP end-to-end. No operator action is needed to keep emitting; a formal OFV declaration is required when DGII confirms the episode.

What Mosce ERP does automatically

1. Generates the e-CF in offline mode and signs it with your certificate without contacting DGII. Your client receives the Printed Representation with the regulated notice.
2. Queues the e-CF in an internal contingency queue that is drained automatically when DGII recovers.
3. Monitors the DGII service continuously. When it confirms recovery, it transmits the queue at the permitted rate (8 documents per second per taxpayer).
4. Flags any e-CF that crosses the 72-hour mark without being delivered and exposes it on the "Past SLA" screen so you can decide document by document.
5. Shows a non-blocking banner reminding you to close the episode in OFV. Emission continues in the meantime.

The notice on the Printed Representation

Per DGII Informe Técnico e-CF v1.0 §19.1: "For the delivery of goods or provision of services, it is mandatory to issue the Printed Representation of the e-CF, incorporating the notice: 'e-CF emitido en modalidad de contingencia'. Said voucher may be fiscally validated once the indicated period has elapsed."

The full notice that Mosce ERP prints on each Printed Representation issued during Loss of Connectivity comes from the Instructivo de Contingencia FE:

"e-CF emitido en modalidad de Contingencia, el cual podrá ser consultado para su validez fiscal, a partir de las setenta y dos (72) horas."

Your client can use that Printed Representation immediately for their internal records. Fiscal validity with DGII is confirmed when the e-CF is delivered and validated - which is why the notice mentions 72 hours.

When Mosce ERP declares contingency - and when it does not

Mosce ERP monitors connectivity with DGII continuously. Not every gap is a contingency. A short intermittency (roughly 3 minutes without a response) is treated as a transient blip: the offline queue activates immediately so no transaction is lost, but no formal episode is registered and no OFV entry declaration is needed. If the failure clearly persists beyond that buffer (approximately 8 consecutive minutes), Mosce ERP does declare the formal episode and the OFV reminder banner appears - to be presented when the episode closes.

Automatic exit + pending OFV declaration

When DGII recovers, invoicing resumes automatically - you do not need to take any action in Mosce ERP to start emitting again. The offline queue drains in the background and new e-CFs travel in real time. What does require action is the exit declaration in OFV: DGII requires you to register the confirmation ID in Mosce ERP to close the audit record. A non-blocking banner reminds you until you do it; invoicing does not stop because of that step.

The 72-hour window as a decision point

Per Decreto 587-24, Art. 40 (Regulation implementing Law 32-23) - cited by the Instructivo de Contingencia FE (page 4) and by Informe Técnico e-CF v1.0 §19.1: e-CFs generated in offline mode must be sent to DGII "within a maximum period of seventy-two (72) hours".

If a contingency lasts long enough for some queued e-CFs to cross that window, Mosce ERP does not automatically mark them as failed. Instead, it labels them "Past SLA" and lists them on a review screen. You decide, document by document:

• Keep retrying delivery - valid when there is evidence that DGII was unreachable throughout the entire episode.
• Cancel the e-CF locally and issue a replacement e-CF that references the original with <CodigoModificacion>4</CodigoModificacion> (Replacement of NCF issued in contingency).

Mosce ERP does not make that fiscal decision for you - your accountant makes it and Mosce ERP records the decision. The "N e-CFs past 72-hour SLA" banner links directly to the review screen when there are overdue documents.

Past-SLA review screen - step by step

Access it at Fiscal → Contingency → Past-SLA Review. The screen lists every e-CF that crossed the 72-hour delivery window without reaching DGII. Each row shows:

Each row's action menu offers two options:

• Keep retrying - opens a confirmation dialog with an optional field to record an audit note (the reason for continuing to retry). The document stays in queue and keeps attempting delivery to DGII. The note is stored in the internal audit history.
• Cancel and issue replacement - Mosce ERP initiates the cancellation of the e-CF with DGII and, once confirmed, automatically takes you to the replacement creation form with the original document's context pre-loaded.

Users without the fiscal:past-sla:decide permission see the screen in read-only mode, with no action options. This is a high-trust permission that does not come in roles by default - assign it only to those who should make these fiscal decisions.

Mode 2 - Technical Incapacity (taxpayer action required)

Per DGII Instructivo de Contingencia FE - Estado de Contingencia §2 (February 2026, page 4): "When the electronic issuer is not technically capable of emitting e-CFs: the taxpayer must issue authorized non-electronic fiscal vouchers. This contingency may not exceed 15 calendar days. It must be reported to DGII through the established mechanism via the Virtual Office."

This mode cannot be automated by Mosce ERP because, by definition, Mosce ERP is the piece that has failed. The branch cannot wait - it has customers asking for invoices. DGII regulations allow selling with a paper Serie B voucher for up to 15 calendar days, provided the episode is reported in the OFV.

What happens when Mosce ERP enters Technical Incapacity

1. Mosce ERP pauses e-CF emission. An action-required banner appears and invoicing forms are blocked.
2. The taxpayer issues Serie B on paper off-platform from their pre-printed stationery. The client receives that voucher and uses it normally to support costs, expenses, and tax credit - DGII regulations allow this while the episode is declared.
3. The taxpayer submits the OFV entry declaration (Facturación Electrónica → Contingencia FE → Declaración Entrada en Contingencia, mode Total or Partial as applicable).
4. When Mosce ERP recovers, the banner changes. It now asks you to register the OFV exit declaration and opens the window for emitting replacement e-CFs.

The declaration goes in both OFV and Mosce ERP - both steps are required

DGII requires the formal declaration to be made in the Virtual Office with your digital certificate. Mosce ERP now has its own dialogs so you can register the ID that OFV returns, keeping the episode fully traced in both systems.

Two-part flow:

1. Declare in OFV (always required): Virtual Office → Facturación Electrónica → Contingencia FE → Declaración Entrada en Contingencia. Choose Total (affects the entire operation) or Partial (affects one or several branches). Fill in the reason in the Description field and Save. OFV confirms with a declaration ID.
2. Register the ID in Mosce ERP (new): from Settings → Fiscal → Contingency, press Declare Contingency Entry. The dialog asks for:
   • Reason (radio): Loss of Connectivity or Technical Incapacity.
   • Mode (radio): Total or Partial.
   • Affected branches (dynamic rows, visible only if you selected Partial): identifiers of the branches that are out of service.
   • Contingency Entry Declaration ID (required text field): the ID delivered by OFV when you saved.
   • Description / detailed reason (free text, optional): you can copy it from the Description field you used in OFV.

For declaring exit the process is analogous:

1. Declare exit in OFV: Virtual Office → Facturación Electrónica → Contingencia FE → Declaración Salida de Contingencia. Brief summary of the closure and Save. OFV confirms with an exit ID.
2. Register in Mosce ERP: from Settings → Fiscal → Contingency, press Declare Contingency Exit. The dialog asks only for the Exit Declaration ID returned by OFV.

DGII's Histórico de Contingencias lists all reported episodes; the OFV inbox records entry and exit notifications. Mosce ERP maintains its own history in the Contingency tab with the same IDs, so the audit trail is complete on both sides.

Both dialogs require the fiscal:contingency:declare permission. The OWNER and ADMIN roles have it by default; for an external accountant with a custom role you will need to add that permission. See Users, roles and permissions.

When Mosce ERP auto-detected the episode without a prior declaration

If DGII connectivity failed while nobody was in the Virtual Office, Mosce ERP may have opened the episode through its own monitoring before the administrator submitted the formal declaration. In that case the episode starts without an OFV entry ID.

Mosce ERP shows a non-blocking banner reminding you that the auto-detected episode needs its OFV entry declaration. To register it:

1. Go to OFV and submit the Declaración Entrada en Contingencia in the usual way.
2. From the banner (or from Settings → Fiscal → Contingency in the history), press Register Declaration. The dialog asks only for the OFV entry ID.

The banner disappears once the ID is registered. Invoicing does not stop in the meantime.

One for one: one Serie B = one replacement e-CF

Per DGII Formato e-CF v1.0 §F.1, <NCFModificado> validation (October 2025, page 56): "Conditional on the e-CF emission corresponding to a replacement of a non-electronic Fiscal Voucher issued in contingency, it must be validated that the type of the modified NCF is equivalent to the type of e-CF being emitted."

DGII defines <NCFModificado> as a single-value xs:string field. There is no bulk replacement. Each paper Serie B voucher issued during the episode corresponds to one replacement e-CF. If you issued 80 invoices on paper over 5 days, you will emit 80 individual e-CFs in Mosce ERP within the 30-day window, each one referencing a Serie B number. This is a DGII specification requirement; it is not a product decision.

Additionally, the type of the replacement e-CF must match the type of the equivalent Serie B voucher (B01→E31, B02→E32, B03→E33, B04→E34, B11→E41, etc.). Mosce ERP validates that mapping when creating the replacement.

What Mosce ERP writes automatically in the replacement

Per DGII Formato e-CF v1.0 §F.4 (October 2025, pages 56-57) - the canonical modification codes. Code 4 = Replacement of NCF issued in contingency applies to any e-CF type that is equivalent to the replaced Serie B.

When you create a replacement e-CF in Mosce ERP - whether for a Serie B issued during a Technical Incapacity or for a queued e-CF you decided to cancel after 72 hours - Mosce ERP automatically writes DGII modification code 4 (Replacement of NCF issued in contingency) in the replacement's reference block. It also fills in <NCFModificado> with the source voucher number. You do not need to remember any of those technical fields.

Important: Replacement e-CFs are sent to DGII only, not to the recipient. "These e-CFs are sent only to DGII, not to the recipient. The recipient may support their costs, expenses, and tax credit with the ordinary voucher already received." Your client already has their paper Serie B - the replacement e-CF is an exclusively fiscal artifact, so that your traceability record with DGII is complete.

Replacement e-CF creation form - step by step

Access it at Fiscal → Replacements → New replacement. You also arrive here from the Past-SLA screen by choosing Cancel and issue replacement on a row, in which case the form arrives with the original document's context pre-loaded.

The form first shows the context of the active contingency episode - the system automatically identifies the open replacement window, displays the days remaining until the deadline (30 days from recovery) and the closing date. You do not choose the episode from a list: the system uses the current open window.

If the window has expired, the form shows an amber warning. Users with the fiscal:replacement:override-window permission (or the OWNER role) also see a checkbox to accept the replacement out of window and proceed anyway. Without that permission the form blocks submission.

Section 1 - Paper voucher:

Section 2 - e-CF details:

Section 3 - Line items:

At least one line is required. Each line has: description (up to 80 characters), quantity, unit price, and ITBIS rate. The subtotal, ITBIS, and total are calculated automatically in the totals section - you do not enter them manually.

Once submitted, the replacement is transmitted exclusively to DGII. The form confirms the submission with the identifier of the generated document.

The 30-day window after recovery

Per Informe Técnico e-CF v1.0 §19.3: "Once the contingency due to the impossibility of emitting e-CFs has been resolved, the taxpayer must, within a maximum period of thirty (30) calendar days: generate and send to DGII the e-CFs corresponding to the operations carried out during the contingency period, and reference the non-electronic vouchers previously issued, in accordance with the technical specifications established by DGII."

As soon as Mosce ERP is operational again, the 30-calendar-day window to emit replacement e-CFs opens. Mosce ERP shows a banner with the deadline and a countdown of days remaining. Once the window closes, the paper Serie B vouchers remain as the sole fiscal evidence on the taxpayer's side; replacement e-CFs submitted after that point may not be accepted.

DGII Contingency - more than 15 business days

Per DGII Instructivo de Contingencia FE - Consideraciones importantes (page 11) and Informe Técnico e-CF v1.0 §19.5: "If the DGII contingency lasts more than 15 business days, the Virtual Office (OFV) will enable the option to submit sales, purchases, expenses, costs, withholding, and other books, operating ordinarily with non-electronic vouchers."

When DGII exceeds 15 business days (working days, distinct from the 15 calendar days of Technical Incapacity), it enables submission of Books 606/607/608 in the OFV to operate with ordinary vouchers for the duration of the incident. If you reach that scenario, reports are handled from DGII Reports.

Worked example - Loss of Connectivity

Scenario: Friday 2:00 PM. The local internet connection starts failing at 2:08 PM; the branch sells for almost 6 hours until closing at 8:00 PM.

1. 2:08 - 2:11 PM - Silent monitoring buffer. After a few consecutive minutes without a DGII response, Mosce ERP activates the offline queue but does not yet declare the episode. Emission keeps working; no banner appears for the operator.
2. 2:18 PM - Episode declared. The failure persists beyond the extended buffer (~8 consecutive minutes). Mosce ERP formally declares the episode as Loss of Connectivity and the banner appears reminding the administrator to submit the Entry Declaration in OFV.
3. 2:18 PM to 8:00 PM - Normal operation. Cashiers emit 50 e-CFs, each signed locally with the regulated notice "e-CF emitido en modalidad de Contingencia, el cual podrá ser consultado para su validez fiscal, a partir de las setenta y dos (72) horas". Clients leave with their Printed Representations and do not notice anything unusual.
4. Saturday 9:00 AM - DGII recovers. Mosce ERP detects successful probes, enters Draining queue state, and delivers the 50 documents at 8 per second. New emissions travel in real time.
5. Saturday 9:30 AM - Pending OFV banner. Reminder to submit the exit declaration; invoicing continues normally.
6. Monday 9:00 AM - Closure. The administrator submits the Contingency Exit Declaration in OFV, receives the confirmation ID, and registers it in Mosce ERP via Settings → Fiscal → Contingency → Declare Contingency Exit. The episode is closed in both systems. No Serie B was issued, no <CodigoModificacion>4 was used: the 50 e-CFs are originals delivered with a delay.

Worked example - Technical Incapacity

Scenario: Friday at 4:30 PM, the taxpayer's DGII digital certificate expires and an error during renewal leaves Mosce ERP unable to sign e-CFs. The company serves walk-in customers and cannot wait.

What happens:

1. 4:30 PM - Mosce ERP enters Technical Incapacity. The system detects the signing error and pauses emission. The Contingency mode - Incapacidad Técnica banner appears, warning that Mosce ERP cannot issue e-CFs at this time and that you must issue paper Serie B vouchers from your pre-printed authorised stationery.
2. 4:35 PM - OFV entry declaration + registration in Mosce ERP. The administrator logs into the Virtual Office with their contributor certificate, navigates to Facturación Electrónica → Contingencia FE → Declaración Entrada en Contingencia, selects mode Total, writes the reason ("Digital certificate expiration - renewal in progress"), Saves, and receives the confirmation ID. They then open Settings → Fiscal → Contingency → Declare Contingency Entry, select Reason Technical Incapacity, Mode Total, paste the OFV ID and save.
3. Friday 4:30 PM to Tuesday 11:00 AM - Operation with paper Serie B. For 4 days the company serves clients with their pre-printed Serie B stationery, issuing 18 paper invoices, each with its Serie B number (B01... or B02... as applicable). Each client leaves with their paper voucher, valid to support costs, expenses, and tax credit. They keep a manual record of each number issued (salesperson, date, amount, client's RNC, voucher type).
4. Tuesday 11:00 AM - Mosce ERP recovers. The new certificate is loaded, a test signature passes, Mosce ERP returns to normal state. Emission of new e-CFs resumes its normal flow. The Replacement window active banner appears, with the count of calendar days remaining.
5. Tuesday 11:15 AM - OFV exit declaration + registration in Mosce ERP. The administrator declares exit in OFV (Declaración Salida de Contingencia) with a brief summary and receives the confirmation ID. In Settings → Fiscal → Contingency → Declare Contingency Exit they paste that ID. The episode is closed in both systems.
6. Tuesday to Friday - Replacements. Over the following days, the accountant enters Mosce ERP and creates 18 individual replacement e-CFs from Fiscal → Replacements → New replacement, one per Serie B issued (remember: 1:1, there is no bulk replacement). For each: they enter the paper Serie B number in the Voucher number field (the system detects the B0x prefix and deduces the e-CF type automatically), fill in the paper issue date, review the e-CF type (B01→E31, B02→E32, etc.), add the line items with description, quantity, price, and ITBIS rate, and submit. Mosce ERP automatically writes <CodigoModificacion>4</CodigoModificacion> and <NCFModificado> in the reference block. The 18 e-CFs are sent to DGII only - not to the client, because the client already has their Serie B.
7. Closure. The history contains: 18 paper Serie B vouchers, 18 Accepted replacement e-CFs, one entry and one exit in OFV, and a 30-day clock that closed before the deadline. Complete fiscal traceability.

Frequently asked questions

Can I keep selling during a contingency?

Yes, in both modes. During Loss of Connectivity emission keeps working inside Mosce ERP with no action required - e-CFs are signed locally and delivered when DGII recovers. During Technical Incapacity you must issue paper Serie B vouchers from the pre-printed stationery you keep on hand for these cases; you will operate outside Mosce ERP for a few days and declare the episode in OFV.

What happens with my POS?

The POS keeps processing payments and recording sales locally. During Loss of Connectivity the POS emits the e-CF with the regulated notice on its Printed Representation; the client takes the voucher and DGII synchronization happens in the background. During Technical Incapacity, while Mosce ERP is down, the POS cannot generate e-CFs; the branch collects payment and hands the client a paper Serie B from the pre-printed stationery; when Mosce ERP recovers those Serie B vouchers are replaced by the corresponding e-CFs within 30 days.

What does my client receive?

During Loss of Connectivity they receive the Printed Representation (RI) of the e-CF with the notice "e-CF emitido en modalidad de Contingencia, el cual podrá ser consultado para su validez fiscal, a partir de las setenta y dos (72) horas". It is fiscally valid for the client from the moment you hand it to them; validity with DGII is consolidated when the e-CF is delivered and validated.

During Technical Incapacity they receive the paper Serie B voucher from the taxpayer's pre-printed stationery. That paper is the definitive fiscal voucher for the client - a subsequent e-CF is not sent to them, because replacements go only to DGII. Your client supports their cost, expense, or tax credit with the Serie B they already hold.

Why does Mosce ERP absorb some blips but require OFV for others?

DGII distinguishes between transient intermittency and a formal contingency. Full details in When Mosce ERP declares contingency - and when it does not.

What happens to an e-CF that crosses the 72-hour window?

Mosce ERP does not automatically mark it as failed; it appears on the Past-SLA Review screen and you decide document by document (keep retrying or cancel and replace). Details in The 72-hour window as a decision point.

How do I know the episode is officially closed?

When three conditions are met: (1) DGII has recovered, (2) the offline queue has fully drained, and (3) you have registered the OFV exit declaration ID in Mosce ERP via the Declare Contingency Exit dialog. The pending OFV banner disappears. During Technical Incapacity the episode is also fully closed when all replacement e-CFs have been emitted within 30 days - the 30-day countdown banner disappears when it reaches zero or when all pending Serie B vouchers are covered.

What if I never submit the OFV exit declaration or register it in Mosce ERP?

Emission of new e-CFs keeps working - that part is independent. What stays open is the audit record of the episode. DGII may ask for the exit ID during a future audit, so the banner remains visible until you register it via the Declare Contingency Exit dialog. The consequence is non-compliance with the notification obligation that Decreto 587-24 requires.

What permission do I need to use the declaration dialogs in Mosce ERP?

fiscal:contingency:declare. The OWNER and ADMIN roles have it automatically. For an external accountant or a branch manager, create a custom role in Settings → Roles and add that permission. See Fiscal module permissions for contingency in this guide.

What do I do if the episode was auto-detected by Mosce ERP but I have not yet submitted the OFV declaration?

Submit the declaration in OFV first. Then, from the "Episode without OFV ID" banner in the Contingency tab, press Register Declaration and paste the ID that OFV returned. Order matters: the OFV declaration is the regulatory source; Mosce ERP simply records the ID for traceability.

Contingency monitoring panel

For taxpayers with high fiscal activity, Mosce ERP includes a monitoring panel in the Contingency tab within the Fiscal module. The panel displays the DGII service status and the volume of in-flight documents in real time.

Available metrics

Episode history

Below the metrics you will find a paginated table with the history of contingency episodes. Each row shows:

• Mode - Loss of Connectivity or Technical Incapacity.
• Start and End of the episode.
• Status - Active / Closed.
• OFV entry ID and OFV exit ID (when recorded).

You can filter the history by status (Active / Closed / All).

How to use the panel for audits

In the event of a DGII audit requiring you to certify past contingency episodes, Mosce ERP's history serves as complementary evidence (alongside the OFV history). You can view the episode, its dates, the OFV entry and exit IDs, and export the information for your audit files.

Querying fiscal health status via API

For integrations and automated monitoring, Mosce ERP exposes a fiscal health status endpoint that your technical team can query:

GET /api/v1/fiscal/health

The response includes:

When to use the endpoint

• To integrate fiscal health status into your own monitoring tools (dashboards, alerts).
• To programmatically verify whether a contingency is active before triggering workflows that depend on DGII connectivity.
• To log DGII availability history in an external system.

Authentication

The endpoint requires a valid authentication token with the fiscal:read permission. This is the same permission used to read the document inbox and contingency status from the UI.

The endpoint reflects the status of Mosce ERP's internal probe, which runs automatically on a schedule to monitor DGII connectivity. It does not call DGII in real time on each query - the reported value may lag the actual DGII state by up to 1-2 minutes.

Fiscal module permissions for contingency

The following permissions are relevant for the contingency functions described in this guide. They are assigned in Settings → Roles to MEMBER users who need access to specific actions. OWNER and ADMIN bypass all these checks.

Common errors

Related

• Cancel and modify e-CFs - DGII modification codes, including Code 4 for replacement.
• Fiscal configuration
• e-CF certificate
• e-CF sequences
• e-CF documents
• Printed Representation and QR
• Voucher inbox
• DGII URLs and certification portal
• DGII reports
• Users, roles and permissions

Last updated: 2026-05-22

Regulatory sources

1. DGII - Instructivo de Contingencia Facturación Electrónica, February 2026. Pages 3-5 (Contingency State, the two modes), pages 6-8 (Entry/Exit Declaration in OFV), pages 9-10 (Contingency Registry / History), page 11 (Important considerations: 30 calendar days for replacements, replacements go only to DGII, DGII Contingency with 15-business-day threshold). Legal references: Law 32-23 Art. 21; Norma 01-2020 Arts. 3 literal (i) and 10; Decreto 587-24 Arts. 40, 41, 42 and 43. Available at the DGII portal.
2. DGII - Informe Técnico e-CF v1.0, March 2026. §19 Contingency Operation, pages 48-50: §19.1 Contingency due to loss of connectivity (72 hours), §19.2 When e-CF emission is not possible (15 calendar days), §19.3 Post-contingency regularization (30 calendar days, e-CFs sent exclusively to DGII), §19.4 Validity of contingency vouchers, §19.5 DGII Contingency (15 business days). Available at the DGII portal.
3. DGII - Formato Comprobante Fiscal Electrónico v1.0, October 2025. §F.1 (page 56) - <NCFModificado> type-equivalence validation. §F.4 (pages 56-57) - the five canonical <CodigoModificacion> codes (1=Cancels, 2=Corrects text, 3=Corrects amounts, 4=Replacement of NCF issued in contingency, 5=Reference to Electronic Consumer Invoice). Code 4 applies to any e-CF type, provided the type matches the equivalent of the replaced paper Serie B (B01→E31, B02→E32, etc., per §F.1). Available at the DGII portal.