Void and modify e-CFs

How to void an issued e-CF, correct text or amount errors, issue a replacement voucher, and what happens to the ITBIS on a return under the 30-day window - includes use cases for each DGII modification code.

Once an e-CF has been sent to the DGII, it cannot be edited directly. Corrections always happen by issuing a new voucher that references the original: a credit or debit note that voids or adjusts it, or a replacement e-CF. Each case has its own DGII modification code.

Reading time: ~10 min

When to use this

An e-CF has a text error (customer name, address) and you need to correct it.
An e-CF has incorrect amounts and you need to reverse or adjust them.
You need to void a voucher that should not have been issued.
Your customer returned merchandise or you want to grant them a later discount.
You came back from a contingency (DGII down or a technical failure) and you have to issue the replacement e-CFs for the paper vouchers you used during that period. See Contingency and backup plans.

Before you start

Your role includes fiscal:manage. Read-only does not allow issuing corrective vouchers.
To issue a replacement e-CF (Code 4) you also need the fiscal:replacement:create permission. If the replacement falls outside the 30-day window, you also need fiscal:replacement:override-window. The OWNER and ADMIN roles do not require additional permissions.
You have the active sequence for the corresponding corrective e-CF type (E33 for a debit note, E34 for a credit note, etc.).
You know the exact number of the original e-CF you are going to reference.
To invert the default ITBIS-withholding behaviour on a return (Code 3) - returning it past 30 days, or withholding it within them - you need the invoices:withhold-tax-override permission. Without it, the return follows the invoice's default. See ITBIS on returns below.

The five DGII modification codes

Per DGII Formato Comprobante Fiscal Electrónico v1.0 §F.4 (pages 56-57): the <CodigoModificacion> field identifies the reason why the corrective e-CF references an earlier one. The five canonical codes are:

Code	DGII name	When it is used
1	Voids	The referenced e-CF must be left without fiscal effect.
2	Corrects text	The original has incorrect text data (name, address, description) without any change to the amounts.
3	Corrects amounts	The amounts in the original are incorrect - a return, price adjustment, calculation error.
4	Replacement of NCF issued in contingency	Replaces a paper Series B voucher issued during a contingency episode, or replaces a queued e-CF whose annulment was filed with the DGII after the regulated deadline expired.
5	Reference to Electronic Consumer Invoice	The e-CF (typically E34) references an electronic Consumer Invoice (E32) as a supporting voucher.

About the name of code 4. "Replacement of NCF issued in contingency" is DGII's literal wording in Formato e-CF v1.0 §F.4 - it includes the acronym NCF (which in the previous regime was the numbering of paper vouchers). Mosce ERP only issues e-CF and never generates a new NCF for you; what code 4 indicates is that the current e-CF replaces a paper Series B voucher previously issued off-platform during a contingency.

Mosce ERP writes the correct code automatically based on the flow you use.

Code 1 - Voids

Use this code when the e-CF should not have existed: wrong recipient, duplicate, sale cancelled without an amount adjustment.

Code 1 is not a button. It is the value Mosce ERP writes into <CodigoModificacion> inside a Credit Note (E34) - or a Debit Note (E33), depending on the type of the original - which references the earlier voucher in <NCFModificado> and is transmitted to the DGII. That note is the instrument that leaves a voucher the DGII already holds without effect.

How to void an e-CF the DGII has already accepted

An Accepted or Conditional e-CF is already held by the DGII and cannot be cancelled: the only route is the credit note, and that note is the void.

In Operations → Invoices, open the original invoice.
Create a Credit Note from the menu action, for the full amount of the voucher. Mosce ERP preloads the original e-CF as a reference.
Issue it. Mosce ERP generates the E34 with <CodigoModificacion>1</CodigoModificacion> and the number of the original in <NCFModificado>, and transmits it to the DGII.

Cancelling the order that produced the invoice reaches the same result: before you confirm, Mosce ERP tells you that an electronic credit note will be issued to void the document with the DGII, and it issues it for you. If the order holds collected money, the route is Refund instead of cancellation.

Important: the Credit Note is the void before the DGII, not an extra step on top of cancelling the voucher. If the note covers only part of the voucher (because an earlier return already covered the rest), Mosce ERP writes Code 3 instead of Code 1: the voucher still ends up fully withdrawn, but through two notes instead of one.

Why the credit note needs an already-accepted document

An Electronic Credit Note carries <NCFModificado>, pointing at the document it corrects, inside the Reference Information section - mandatory on every credit or debit note. Before accepting it, the DGII validates that the referenced document has already been filed with it. A rejected document, or one the invoice never even generated, is not in the DGII's records: there is nothing yet for the note to reference.

That is why the refund dialog only lets you pick the credit note as a refund method once the original invoice's document was already accepted or conditionally accepted by the DGII. In any other case the option shows disabled with the reason written underneath, leaving cash or the customer credit balance as the way out. See Why can't I pick a credit note when refunding? in Returns and refunds for the full detail, with its two distinct reasons.

Per Formato Comprobante Fiscal Electrónico v1.0 §2.1 "La obligatoriedad de cada una de las partes del e-CF" (page 4): the Reference Information section is mandatory (code 1) for the Electronic Credit Note. §F "Información de Referencia" (page 56), field <NCFModificado>, validation a): "Validar que el número de comprobante fiscal modificado haya sido remitido previamente a la DGII" (validate that the referenced document number has already been filed with the DGII).

The Cancel action in the documents inbox

In Fiscal → e-CF Documents, each row's action menu offers Cancel. It is an action on the Mosce ERP record: it marks the voucher as Cancelled and stores the reason in the internal audit trail. It issues no credit note and does not, on its own, send any annulment to the DGII. Do not confuse this action with Code 1 from the previous section: they are two different things.

Mosce ERP does not offer this action - and refuses it if attempted by another route - for a voucher the DGII already holds (Accepted or Conditional), nor for one that is already Cancelled. If you try it on an accepted one, the application answers: "The DGII already accepted this document: void it with a credit note."

How to cancel from the documents inbox

Open Fiscal → e-CF Documents.
Find the e-CF you want to cancel. You can search for it by its number or filter by status.
In the row's action menu, choose Cancel.
In the dialog, type the Cancellation reason (required field). This reason is recorded in the internal audit trail.
Confirm. The cancellation is permanent.

Before you use it. This action leaves a record inside Mosce ERP. If the voucher had already been signed, check with your accountant what has to be declared to the DGII for that number.

Code 2 - Text correction

You issued the e-CF with the customer's name misspelled, the wrong address, or an incorrect description, but the amounts are correct. In that case:

From the documents inbox, open the detail of the original e-CF.
Issue a Credit Note (E34) or the equivalent type with <CodigoModificacion>2</CodigoModificacion>, referencing the number of the original.
The new voucher must have the same amounts as the original (the correction is text-only).

Note: In practice, many accountants prefer to leave the original without effect through a Code 1 note and reissue from scratch instead of using Code 2, because the flow is clearer for the recipient. Both approaches are valid before the DGII.

Code 3 - Amount correction

Use this code when you have to reverse or adjust the economic value of a transaction: merchandise returns, discounts granted after the invoice, price or calculation corrections.

The standard vehicle is the Credit Note (E34) issued from the invoicing module.

Example: Distribuidora La Esperanza, S.R.L. receives a return

The company issued E310000000083 (Fiscal Credit Invoice) for DOP 42,000 + ITBIS. The customer returns merchandise worth DOP 8,000.

In Operations → Invoices, open the original invoice.
Create a Credit Note from the menu action - Mosce ERP preloads the original e-CF as a reference.
Adjust the amount to the value of the return (DOP 8,000 + corresponding ITBIS).
Issue it. Mosce ERP generates an E34 with <CodigoModificacion>3</CodigoModificacion> and the number of the original e-CF in <NCFModificado>.

The customer ends up with the original voucher (E31) plus the credit note (E34) that reduces the amount payable.

ITBIS on returns - the 30-day window

Per Informe Técnico e-CF v1.0 §10 "Correcciones y Anulación de un e-CF" (page 17): "If the electronic credit note is issued after thirty (30) calendar days, counted from the birth of the tax obligation, returns of goods subject to ITBIS may result solely in the restitution of the price paid, without including the return of the ITBIS, as established by Articles 8 and 28 of Regulation 293-11."

When the Code 3 credit note corresponds to a merchandise return, that return's ITBIS can either go back to the customer or stay with the business, depending on how many days have passed since the invoice:

Invoice 30 days old or less: by default, the ITBIS is returned to the customer.
Invoice more than 30 days old: by default, the business withholds it, because the tax has already been declared to the DGII.

The boundary is inclusive: day 30 still returns it; day 31 already withholds it. The count starts from the invoice date, not the return date.

An administrator holding the invoices:withhold-tax-override permission can invert the default in either direction - returning the ITBIS past 30 days, or withholding it within them. Whoever lacks that permission does not see the toggle, and the return follows the invoice's default.

Where you see the ITBIS you kept

The tax the business keeps on those late refunds does not vanish: it is declared as a positive adjustment in the "Otras Operaciones (Positivas)" box of Annex A of the IT-1.

So you do not have to gather it by hand, the Late credit-note ITBIS report, under Reports, gives you that figure grouped by declarable month, with the detail of every credit note backing it. See DGII Reports.

The asymmetry

The two directions do not carry the same weight:

Withholding within 30 days is harmless: the business gives up a refund it was entitled to make, with no further consequence.
Returning past 30 days does have consequences: the credit note will declare to the DGII, with <IndicadorNotaCredito>1</IndicadorNotaCredito>, that it does not carry the right to rebate ITBIS - while the books rebate it anyway when it is returned. One thing is told to the DGII and another to the ledger. That is why only that direction shows a warning before you confirm, and it records who authorized the exception:

"You are about to return the ITBIS even though more than 30 days have passed since the invoice: the document will declare to the DGII that this note does not carry the right to rebate ITBIS, but the books will rebate it anyway. It will be recorded that you authorized this exception."

What the toggle does NOT change

The <IndicadorNotaCredito> field carried in the voucher is calculated solely from two dates - the original invoice's and the credit note's - and nothing else. Neither the permission, nor the toggle, nor any administrator changes it. What the toggle moves is the money: who ends up with the ITBIS. The indicator the DGII receives is the same, whether or not the exception is authorized.

A full return is still full

Returning all of an invoice's merchandise with the ITBIS withheld still closes the order as fully returned, with a zero balance. The withheld ITBIS does not sit half-collected or go back into the collection queue: it is money the customer will never see again, so it counts toward closing the return exactly like cash that was handed back.

Example: an invoice for RD$1,146.00 (base RD$1,020.00 + ITBIS RD$126.00) is returned 35 days later. The customer receives RD$1,020.00, the business withholds RD$126.00 of ITBIS, and the order ends up fully returned with a zero balance - even though what the customer received is less than the invoice total.

For the refund dialog, its methods, and what the user sees on screen, see Returns and refunds.

Code 4 - Replacement of a voucher issued in contingency

Per DGII Formato Comprobante Fiscal Electrónico v1.0 §F.4: code 4 (Replacement of NCF issued in contingency) applies to any e-CF type whose type matches the equivalent of the Series B voucher being replaced.

This code covers two distinct scenarios:

Scenario A - Replacement of paper Series B (after Technical Incapacity)

When the system was technically incapacitated to issue e-CFs, the taxpayer operated with paper Series B vouchers. Once the service is restored, they have 30 calendar days to issue a replacement e-CF for each paper voucher used, from Fiscal → Replacements → New replacement.

Key characteristics:

One Series B = one replacement e-CF. There is no bulk replacement; each paper voucher requires its own electronic voucher. This is defined by the DGII specification.
The e-CF type must match the equivalent of the Series B (B01→E31, B02→E32, B03→E33, B04→E34, B11→E41, etc.). Mosce ERP detects it automatically when you enter the Series B number in the Voucher number field.
The replacement e-CF is sent only to the DGII, not to the recipient. Your customer already has their original paper voucher.

Scenario B - Replacement of a queued e-CF that crossed the regulated 72-hour deadline

When an e-CF in the contingency queue could not be delivered to the DGII within the regulated 72 hours, Mosce ERP surfaces it on the Fiscal → Contingency → Past-SLA Review screen. If you decide to cancel it instead of continuing to retry, you choose Void and issue replacement on that row. The flow is:

Mosce ERP starts the e-CF cancellation via the DGII.
Once the DGII accepts the cancellation, Mosce ERP takes you to the replacement form with the original document context preloaded.
The replacement is issued with <CodigoModificacion>4</CodigoModificacion> referencing the number of the cancelled original e-CF.

Note: This replacement flow is part of contingency handling. For the complete guide - what triggers the 72-hour deadline, how the Past-SLA screen works, and the 30-day clock for paper replacements - read Contingency and backup plans.

What Mosce ERP writes automatically

When you create the replacement in Mosce ERP (whether from the Past-SLA screen or directly from Fiscal → Replacements → New replacement), you complete the form fields: the number of the paper voucher or the original e-CF in the Voucher number field, the issue date, and the detail lines. Mosce ERP fills in automatically:

<CodigoModificacion>4</CodigoModificacion> in the reference block.
<NCFModificado> with the number of the referenced voucher (Series B or original e-CF).
The e-CF type according to the B→E mapping (auto-detected from the number prefix as you type it).

For types E33 (Debit Note) and E34 (Credit Note), the form shows an additional optional Modification reason field, which corresponds to the e-CF's <RazonModificacion>.

You do not have to remember any of the technical reference fields; you only provide the source voucher data and the detail lines.

Code 5 - Reference to an Electronic Consumer Invoice

Use this code when you issue a Credit Note (E34) that references a Consumer Invoice (E32). The DGII regulation requires distinguishing whether the reference voucher is a fiscal credit invoice (E31) or a consumer invoice (E32) because the recipient's fiscal treatment differs.

Mosce ERP applies Code 5 automatically when it detects that the referenced voucher is an E32.

Quick reference table

I want to...	Corrective e-CF type	Code
Void a voucher the DGII has already accepted	E34 (Credit Note) or E33 (Debit Note), depending on the original type	1
Correct name / address / text without changing amounts	E34 or another type with corrected data	2
Return / reverse / adjust amounts	E34 (Credit Note)	3
Replace a paper Series B after a contingency	E31/E32/E33/E34/E41/etc. per equivalence	4
Replace a queued e-CF cancelled after 72 h	Same type as the cancelled original e-CF	4
Credit note referencing a consumer E32	E34	5

Common errors

Symptom	Likely cause	Solution
DGII rejects the replacement e-CF	The replacement type does not match the original Series B	Check the equivalence (B01→E31, B02→E32, etc.)
The replacement form does not appear or is locked	The 30-day window expired, there is no active episode, or you lack `fiscal:replacement:create`	Check the status in Fiscal → Contingency; if the window expired and you have authorization, use the out-of-window acceptance checkbox; if you lack the permission, ask your administrator
The recipient claims they did not receive the replacement	Expected behavior	Replacements (Code 4) go only to the DGII, not to the recipient
I cannot cancel an accepted e-CF	This is the correct behaviour: a voucher the DGII has already accepted (Accepted or Conditional) is not cancelled	Issue a Credit Note (E34) for the full amount from the original invoice, or cancel the order that produced it. That note is the void before the DGII: there is no need to also cancel the voucher
I don't see the toggle to withhold or return the ITBIS on a return	You lack the `invoices:withhold-tax-override` permission	The return still goes through, following the invoice's default (returns within 30 days, withholds past that window); ask an administrator who holds that permission to adjust it if needed

Contingency and backup plans - complete flow of Code 4 replacements after a contingency, the 30-day window and the Past SLA screen.
e-CF Documents - documents inbox with DGII statuses and the Cancel action.
e-CF Sequences - management of active sequences for each e-CF type.
Fiscal configuration - issuer data required for any corrective voucher.
Returns and refunds - the refund dialog, its methods, and what the user sees on screen about the ITBIS window.

Last updated: 2026-08-31

Regulatory sources

DGII - Formato Comprobante Fiscal Electrónico v1.0, October 2025. §F.4 (pages 56-57) - the five canonical <CodigoModificacion> codes: 1=Voids, 2=Corrects Text, 3=Corrects amounts, 4=Replacement of NCF issued in contingency, 5=Reference to Electronic Consumer Invoice. §F.1 (page 56) - <NCFModificado> validation of type equivalence between the Series B and the replacement e-CF. Available on the DGII portal.
DGII - Informe Técnico e-CF v1.0. §10 (page 17) - corrections and the annulment of an e-CF are carried out solely through electronic credit or debit notes; the e-NCF Annulment service is reserved for signed e-CFs that have not yet been sent either to the DGII or to the recipient, and for ranges of unused sequences. The same section states that an e-CF rejected by the DGII is not considered valid and that the issuer must issue a new one and replace the one delivered to the recipient. §4.10 (page 9) - same scope for the annulment service. §9.1 (page 17) - "Aceptado Condicional" is an acceptance carrying an observation to correct in future submissions, so the DGII keeps the voucher on file as valid. Available on the DGII portal.
DGII - Informe Técnico e-CF v1.0. §10 (page 17) - the 30-calendar-day window, counted from the birth of the tax obligation, for a return of goods subject to ITBIS to also include the return of the tax (Articles 8 and 28 of Regulation 293-11); past that window, the credit note only restitutes the price paid. DGII - Formato Comprobante Fiscal Electrónico v1.0, October 2025 - the indicator table: the <IndicadorNotaCredito> field takes value 0 if the affected e-CF's emission date is 30 calendar days or less, and 1 if it is more. Available on the DGII portal.
DGII - Formato Comprobante Fiscal Electrónico v1.0, October 2025. §2.1 (page 4) - the Reference Information section is mandatory (code 1) for the Electronic Credit Note. §F (page 56), field <NCFModificado>, validation a) - "Validar que el número de comprobante fiscal modificado haya sido remitido previamente a la DGII": the basis for why a credit note can only reference a document already accepted by the DGII. Available on the DGII portal.

Void and modify e-CFs

On this page