Law 32-23 and Norma General 01-2020 establish ten types of active electronic fiscal voucher for Dominican taxpayers. Each has a code (E31, E32, E33, E34, E41, E43, E44, E45, E46, E47), its own XSD published by the DGII, and a specific fiscal meaning.
Confusing one type with another is the most common cause of rejection when going into production. This article walks through all ten with real cases, the XSD’s critical fields, and the errors we see the DGII reject in the first weeks of adoption.
Map of the ten types
The DGII reserves code E42 (Registro Único de Ingresos) in the nomenclature, but it is not currently implemented in production. The active types are the ten listed below.
| Code | DGII name | Who issues to whom | When |
|---|---|---|---|
| E31 | Fiscal credit invoice | Taxpayer → taxpayer with RNC | Business-to-business purchase/sale that supports ITBIS fiscal credit |
| E32 | Consumer invoice | Taxpayer → final consumer | Retail sale; supports RFCE |
| E33 | Electronic debit note | Seller → buyer | Adjusts a prior e-CF upward |
| E34 | Electronic credit note | Seller → buyer | Adjusts a prior e-CF downward |
| E41 | Purchases | Taxpayer → DGII | Purchase from unregistered persons |
| E43 | Minor expenses | Taxpayer → DGII | Small payments without a supplier receipt |
| E44 | Special regimes | Taxpayer → beneficiary | Free zones, tourism, renewable energy |
| E45 | Government | Taxpayer → government entity | Sales to the Dominican State |
| E46 | Exports | Taxpayer → foreign client | Sales abroad, zero rate |
| E47 | Foreign payments | Taxpayer → non-resident | Dominican-source income paid to non-residents |
All share the same lifecycle: created, validated against XSD, signed with a tax digital certificate, submitted to the DGII web service, and returned with one of five statuses — In Process, Accepted, Conditionally Accepted, Rejected, or Cancelled (Norma 01-2020).
E31 — Fiscal credit invoice
When to issue. Any sale from one registered taxpayer to another with a valid RNC. This is the voucher that supports the ITBIS fiscal credit and income tax deductibility for the recipient.
What the XSD requires. Issuer and buyer RNC, e-NCF sequence, line items with itemized ITBIS, totals, applicable withholdings, and digital signature. The presence and validity of the buyer’s RNC is non-negotiable.
Common errors.
- Inactive or non-existent recipient RNC in the DGII registry.
- Mismatch between line-level ITBIS and the voucher total.
- Wrong ITBIS rate applied to exempt products.
- ITBIS or ISR withholding omitted when the recipient is subject to a withholding regime.
E32 — Consumer invoice
When to issue. Retail sale to a final consumer. The difference from E31 is that the recipient does not need to provide an RNC; the voucher does not generate fiscal credit for the buyer.
What the XSD requires. Issuer data, sequence, line items with ITBIS and totals. When the flow applies the Electronic Consumer Invoice Summary (RFCE), the DGII receives a consolidated summary instead of each individual e-CF; factura.com.do supports this natively.
Common errors.
- Issuing E32 to a B2B client who needs E31 — the buyer loses the fiscal credit.
- Forgetting to break out ITBIS when invoicing a mix of taxed and exempt products.
- Skipping RFCE on qualifying transactions and sending thousands of unnecessary individual e-CF.
E33 — Electronic debit note
When to issue. To adjust a previously issued e-CF upward: late-payment interest, surcharges, price or quantity differences detected after issuance.
What the XSD requires. Mandatory reference to the original e-CF via referenceSequence (NCF) and referenceCreatedAt (issuance date), plus a modificationCode indicating the reason for the adjustment. The codes active in factura.com.do are 1 (cancels the original), 2 (corrects text without touching amounts), and 3 (corrects amount, numeric adjustment to the balance). The four typical late-charge scenarios — interest, surcharges, differences, and adjustments — fit code 3.
Common errors.
- Issuing a debit note that exceeds the original invoice amount. The system validates and blocks the submission.
- Referencing an NCF that does not exist or has already been cancelled.
- Using E33 when the adjustment is downward (that requires E34).
E34 — Electronic credit note
When to issue. To adjust a previously issued e-CF downward: full or partial returns, subsequent discounts, cancellations, and rebates. Always references the original e-CF.
What the XSD requires. The same reference fields as E33 (referenceSequence, referenceCreatedAt, modificationCode), plus the returned line items with their associated taxes. A full cancellation replicates all lines of the original voucher with the same quantities; the DGII cancels the entire fiscal effect. A partial return describes only what was returned.
Common errors.
- Issuing E34 without the reference to the original NCF — guaranteed DGII rejection.
- Returning more than what was invoiced due to a data-entry error.
- Treating a cancellation as a partial return (or vice versa) and misaligning the accounting reconciliation.
E41 — Purchases
When to issue. The taxpayer itself issues the voucher for its purchase from persons not registered in the registry — informal suppliers, independent professionals who do not invoice, cases where the supplier provides no receipt. The buyer uses this e-CF to support the expense for tax purposes.
What the XSD requires. Supplier RNC or national ID (cédula) where applicable, description of the purchased good or service, amount, ITBIS if applicable, and the issuing taxpayer’s signature.
Common errors.
- Using E41 when the supplier is registered and should have issued E31 — the DGII flags the inappropriate substitution.
- Omitting the supplier’s national ID when purchasing from an identifiable individual.
- Consolidating multiple purchases into a single E41 when they should go individually.
E43 — Minor expenses
When to issue. Supports small payments made by company staff when the supplier provides no receipt: petty cash, taxis, operating tips, counter purchases at establishments without electronic invoicing.
What the XSD requires. Expense description, amount, date, and signature. Granularity is per expense, not consolidated.
Common errors.
- Using E43 for expenses that exceed reasonable “minor” limits — the DGII may flag abuse of the regime.
- Confusing E43 with E41 when there is an identifiable purchase from an unregistered supplier.
- Accumulating multiple expenses in a single e-CF to reduce volume — breaks traceability.
E44 — Special regimes
When to issue. Transactions with beneficiaries of special regimes: free zones, tourism, renewable energy, and other incentives under Dominican law. The fiscal treatment differs from a regular sale because the beneficiary is exempt or subject to reduced rates.
What the XSD requires. Identification of the applicable regime, beneficiary RNC, line items with the corresponding fiscal treatment, and signature.
Common errors.
- Applying free-zone treatment when the client is not current in the regime.
- Using E44 for a regular sale instead of E31 — ITBIS applies as a normal taxed sale.
- Mixing special-regime lines with regular lines in the same e-CF.
E45 — Government
When to issue. Sales to the Dominican State — ministries, city halls, autonomous institutions, and affiliated entities. These have specific fiscal treatment and their own withholding requirements.
What the XSD requires. Purchasing government entity RNC, sequence, line items with ITBIS, and applicable entity withholdings. Government withholdings can differ from standard B2B withholdings.
Common errors.
- Issuing E31 instead of E45 to a government entity — the DGII flags the inconsistency.
- Applying the wrong withholding or not applying the one that corresponds to the government regime.
- Failing to retain the withholding certificate the government entity provides to the taxpayer.
E46 — Exports
When to issue. Sales abroad. Documents a transaction taxed at zero rate: the buyer is a foreign client (person or company outside Dominican territory) and the goods or services are exported.
What the XSD requires. Foreign client data, description of the exported good or service, value in foreign currency converted to Dominican pesos using the day’s exchange rate, line items with ITBIS at zero percent. When payment is in foreign currency, the system resolves the rate against the Dominican peso for automatic conversions.
Common errors.
- Applying ITBIS to an export due to a product configuration error.
- Omitting the conversion to Dominican pesos when the voucher is invoiced in USD or EUR.
- Confusing E46 with E44 when the client is a local free zone — they are different treatments.
E47 — Foreign payments
When to issue. Supports payments for Dominican-source taxable income that the local taxpayer makes to a non-resident — technical services from abroad, royalties, interest, dividends, and other concepts covered by Law 11-92 (Tax Code).
What the XSD requires. Identification of the non-resident recipient, payment description, currency amount and conversion, applicable ISR withholding on non-residents. The withholdings module manages the specific withholding regimes for non-residents.
Common errors.
- Omitting ISR withholding on non-residents when applicable — a frequent source of adjustments and penalties.
- Using E47 for payments to residents; E31 with withholding applies instead, if applicable.
- Not retaining documentation of the payment purpose to support the transaction before the DGII.
Notes E33 vs E34 — the practical rule
Three fields survive almost every rejection when dealing with notes:
referenceSequence— the NCF of the original voucher.referenceCreatedAt— the issuance date of the original.modificationCode— the reason:1(cancels),2(corrects text),3(corrects amount).
If the system allows submitting a note without these three fields, rejection is guaranteed. When modificationCode is 3 (Corrects Amount), the system compares the note total against the referenced original voucher total: if it exceeds it, it rejects with a specific message.
How factura.com.do issues them
factura.com.do covers all ten active types from a single platform. The digital signature is applied with a qualified X.509 certificate in an encrypted vault, the XML is generated per the DGII’s official schema, the status of each submission is checked automatically, and the legal archive is maintained for ten years per Article 24 of Law 32-23.
ERP connectivity, credit and debit notes with note → original e-CF traceability, and the 606, 607, and 608 reports are generated from the issued and received e-CF with no intermediate step.
If you are still deciding on timelines, the article e-CF calendar 2026: how to prepare before November 15 covers where you stand and what to have ready. For the technical detail by type, see /producto. To integrate your ERP with the API, see /desarrolladores.