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. Technical Incapacity is a different figure and the taxpayer declares it: it means your system is not in a position to emit, so during the episode comprobantes are issued as Serie B, outside the electronic invoicing system (DGII allows up to 15 calendar days). That episode does not close by itself: it ends when the taxpayer files the Exit Declaration in the Virtual Office and registers its identifier in Mosce ERP. From then on the taxpayer has 30 calendar days to emit the replacement e-CFs that reference each Serie B in <InformacionDeReferencia>, and those replacements are sent to DGII only, not to the recipient.

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. The OWNER role bypasses all these checks. ADMIN does not: its factory template carries only fiscal:contingency:declare and fiscal:replacement:create; fiscal:read, fiscal:manage, fiscal:past-sla:decide and fiscal:replacement:override-window must be granted in Settings → Roles.
• 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 have worked out how you will issue authorized Serie B comprobantes if you enter Technical Incapacity. DGII defines the Serie B as "the authorized document issued in physical or manual format, without using the electronic invoicing systems": it can come from an authorized booklet or from another invoicing system that issues Serie B, and DGII does not prescribe which. What is the taxpayer's responsibility is having it available: "the issuer must have sequences of Non-Electronic Fiscal Vouchers and hand them to the non-electronic receiver" (Modelos Ilustrativos de RI §4.2, footnote). 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 with DGII and issue a replacement e-CF that references the original with <CodigoModificacion>4</CodigoModificacion> (Replacement of NCF issued in contingency). Mosce ERP files the annulment with DGII: the original voucher moves to Cancellation in Progress and, once DGII confirms it, to Cancelled with DGII.

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.

A waiting-to-send voucher whose sale is undone

A voucher that is Waiting to Send was signed during the outage, and DGII does not have it yet. If the sale is undone before it goes out (the order is cancelled or you decide to cancel the voucher), you do not have to wait for DGII to come back, send it and then correct it: you can cancel it. From Fiscal → e-CF Documents, the Cancel action (or cancelling the order) sends an annulment request to DGII; the voucher moves to Cancellation in Progress and, when DGII accepts it, to Cancelled with DGII. The order asks for a Cancellation type and a Cancellation reason, because they are the reason declared.

• If DGII is still down, the system keeps retrying the annulment for a while. If it still cannot deliver it, the voucher stays in Cancellation in Progress and its detail says it could not be delivered; once DGII is available again, click Retry annulment to send it again.
• If the voucher already went out and DGII has not answered (Pending or No Response), it cannot be cancelled until DGII answers; if DGII accepts it, it is voided with a Credit Note (E34). If DGII rejects it, there is nothing to cancel and a new one is issued.

Per Instructivo de Contingencia FE - Consideraciones importantes (page 11): when DGII systems are unavailable the issuer must store the e-CFs and send them once communication is restored. Per Informe Técnico e-CF v1.0 §4.10 (page 9) and §10 (page 17): the e-NCF Annulment service covers signed e-CFs not yet sent to DGII or to the recipient.

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 Serie B comprobante for up to 15 calendar days, provided the episode is reported in the OFV. And the notification is not a side formality: "only the non-electronic comprobantes issued in contingency and properly notified to DGII will be valid to support costs, expenses and tax credit".

What happens when Mosce ERP enters Technical Incapacity

1. An action-required banner appears and, while the episode is open, Mosce ERP transmits nothing to DGII. The figure means the system is not in a position to emit, so the normal course is to invoice with Serie B outside the platform. But if someone invoices inside it without knowing the state is declared, it does not fail: the comprobante is signed, queued and waits. Nothing leaves for DGII until you register the Exit Declaration.
2. The taxpayer issues Serie B outside the electronic invoicing system. The client receives that comprobante and uses it normally to support costs, expenses, and tax credit - DGII regulations allow this while the episode is declared.
3. The taxpayer files the OFV entry declaration (Facturación Electrónica → Contingencia FE → Declaración Entrada en Contingencia, mode Total or Partial as applicable).
4. The taxpayer, not the system, closes the episode. Mosce ERP cannot detect that its own incapacity ended, so no automatic signal closes a Technical Incapacity episode: the banner keeps asking for the OFV exit declaration, and registering it is what opens the window for emitting the 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.
   • Modality (radio): Modalidad Total or Modalidad Parcial.
   • Affected branches (list of branches, visible only if you selected Modalidad Parcial): tick the active branches of your company that cannot bill electronically. At least one is required; if the incident affects the whole company, use Modalidad Total. If the company has a single branch, it already appears ticked.
   • 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 role has it always and ADMIN has 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 Serie B voucher issued during the episode corresponds to one replacement e-CF. If you issued 80 Serie B invoices 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.

A Serie B is replaced only once. If you try to issue a second replacement for the same number, Mosce ERP refuses it with the notice "This Serie B comprobante was already replaced by an earlier e-CF." Check the documents list before issuing, so you do not repeat one.

Additionally, the type of the replacement e-CF must be the equivalent of the Serie B voucher's type (B01→E31, B02→E32, B14→E44, B15→E45, B16→E46, B17→E47). Only sale comprobantes are replaced from the form: a Serie B note (B03 and B04) and the comprobantes issued in your own name (B11 and B13, which have no customer to bill) cannot be replaced from that screen, and the form says so.

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 Serie B comprobante - 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

Where to reach it. There are two doors, and both require the fiscal:replacement:create permission:

• Settings → Fiscal → Contingency: while the window is open, the Replacements in this episode card shows the days remaining and the Issue replacement button. The same card counts the replacements created, in progress, accepted and stuck.
• The Replacement window active banner, which appears on any screen of the application while the window is open, carries the Issue replacement link (and Go to Replacements, which leads to the card above). Inside the Contingency screen the banner does not repeat the link, because the card already offers it.

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.

If no window is open, the form shows "No active replacement window": replacements can only be issued during the 30 days following the close of a Technical Incapacity episode. With the window open, the form shows Active replacement window at the top, the days remaining and the expiry 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 the Issue outside the replacement window checkbox to proceed anyway. Without that permission, Mosce ERP refuses the submission.

The replacement is billed as an ordinary sale: it generates its own invoice in Mosce ERP, so if the Serie B was left on credit there is a real receivable against which payments can be recorded.

Section 1 - Client and payment:

With Credit, the invoice falls due counting from the date of the paper comprobante, not from the day you issue the replacement. The term comes from the client's credit condition (or the business default), so the receivable ages as if the sale had been invoiced on the day it actually happened. A credit replacement follows the rules of any credit sale: the client must have credit enabled, stay within their limit and have no overdue invoices; otherwise the form says so and you can issue it in cash.

Section 2 - Serie B comprobante:

Section 3 - e-CF details:

Section 4 - Line items:

At least one item is required (Add item button). On each item you can pick a Product (optional) from the catalog, which fills in the line (description, price and ITBIS rate), or leave it blank and type the data by hand:

The Totals (Subtotal, ITBIS and Total) are computed automatically from the items.

To finish, press Issue Replacement e-CF. The screen confirms with "Replacement e-CF created" and the document identifier; the document goes into the DGII submission queue and its e-CF number is assigned once DGII accepts it. From there you can View document or Create another replacement. The replacement is transmitted to DGII only, never to the recipient.

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."

The 30-calendar-day window to emit replacement e-CFs opens with the exit declaration, not with the technical recovery: it is the declared exit that marks DGII's "once the contingency has been resolved". Mosce ERP shows a banner with the deadline and a countdown of days remaining. Once the window closes, the 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 the Contingency mode - Incapacidad Técnica banner appears. It warns that Mosce ERP is not in a position to emit e-CFs at this time and that you must issue authorized Serie B comprobantes outside the electronic invoicing system. Whatever is invoiced inside the platform during the episode is left in the queue, untransmitted.
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 Serie B. For 4 days the company serves clients with its authorized Serie B comprobantes, issued outside the electronic invoicing system. It issues 18 Serie B invoices, each with its number (B01... or B02... as applicable). Each client leaves with their comprobante, valid to support costs, expenses, and tax credit as long as the episode is properly notified to DGII. They keep a record of each number issued (salesperson, date, amount, client's RNC, comprobante type), which is what later feeds the replacements.
4. Tuesday 11:00 AM - the technical cause is resolved. The new certificate is loaded and a test signature passes. The episode stays open: resolving the cause does not close it, because the system has no way of knowing its own incapacity ended. The banner keeps asking for the exit declaration.
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. That closes the episode in both systems, releases the queue (whatever was invoiced during the episode goes out to DGII) and the Replacement window active banner appears with the count of calendar days remaining.
6. Tuesday to Friday - Replacements. Over the following days, the accountant goes to Settings → Fiscal → Contingency and presses Issue replacement on the Replacements in this episode card (or uses the same link on the Replacement window active banner). They create 18 individual replacement e-CFs, one per Serie B issued (remember: 1:1, there is no bulk replacement). For each: they choose the Client and the Payment term (Cash with its register, or Credit, whose due date is counted from the Serie B date), enter the number in the Serie B comprobante number field (the system suggests the e-CF type from the series), fill in the Serie B issue date, review the e-CF type (B01→E31, B02→E32, etc.), add the items (from the catalog or typed by hand), and submit. If they try to replace the same Serie B twice, Mosce ERP refuses the second. 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 Serie B comprobantes, 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 what applies is to issue authorized Serie B outside the electronic invoicing system while the episode lasts, and declare it in the OFV. Invoicing inside the platform is not blocked and does not fail: that comprobante is signed and queued until you register the Exit Declaration.

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 comprobante and DGII synchronization happens in the background. During Technical Incapacity the POS keeps charging, but whatever it emits stays queued, untransmitted, while the episode is open, so what you should hand the client is an authorized Serie B. When you declare the exit, those Serie B comprobantes 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 taxpayer's authorized Serie B comprobante. That comprobante is the definitive one for the client - no later e-CF is delivered 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 role has it always and ADMIN has it by default. 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 users who need access to specific actions. The OWNER role bypasses all these checks. ADMIN does not: its factory template carries only fiscal:contingency:declare and fiscal:replacement:create, and the rest (fiscal:read, fiscal:manage, fiscal:past-sla:decide, fiscal:replacement:override-window) must be granted explicitly.

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-11-01

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.