e-CF Documents

The e-CF Documents tray is the control center for every electronic tax voucher generated from Mosce ERP. Each e-CF appears with its sequence number, type, DGII status, Track ID, and dates. From here you can view the validation status, retry failed submissions, edit fields before resending, cancel a voucher, and download the signed XML or the Printed Representation.

Reading time: ~8 min

What happens if DGII is down or the system fails?

Mosce ERP automatically handles loss of connectivity with DGII - e-CFs are signed locally and delivered within the regulated 72 hours. In the event of a complete technical failure of the system, the taxpayer issues paper Serie B vouchers off-platform and Mosce ERP emits the replacement e-CFs once service is restored. Read the full guide: Contingency and backup plans.

When to use this

• You want to see the status of an e-CF that just went out from an invoice, credit note, or order.
• An emission ended up Rejected and you need to correct and resend it.
• You are going to cancel a voucher and record the reason.
• You need the signed XML of an e-CF to send to the client or the accountant.
• You want to cite the Track ID when checking with DGII support about the status of a submission.

Before you start

• Your role includes fiscal:read. To retry, edit, cancel, or download XML you need fiscal:manage.
• The Fiscal Configuration is saved and there is at least one active sequence of the voucher type.
• The certificate (platform or your own) is valid.

e-CF statuses

When Mosce ERP sends an e-CF to DGII, the voucher may pass through the following statuses:

The statuses Mosce ERP shows are user-facing translations of the technical statuses DGII returns: "e-CF aceptado", "e-CF aceptado condicional", "e-CF rechazado", and "e-CF en proceso" - per Informe Técnico e-CF v1.0 §8 (page 15).

The Track ID

When you send an e-CF to DGII, the DGII system returns a Track ID - a tracking identifier you can use to check the document's status in the DGII web service. In Mosce ERP you find it in the detail of each e-CF (the Track ID DGII column or field).

The Track ID is especially useful when:

• The status is slow to update and you want to verify it directly with DGII.
• You call DGII support and need to identify the specific submission.
• Your accountant needs to cite the document in an audit or claim.

Step by step

1. Open Fiscal → e-CF Documents from the side menu.
2. Use the status tabs to filter: All, Not sent, Pending, Accepted, Conditional, Rejected, Cancelled.
3. Additional filters:
   • Search by e-CF - type the full or partial number.
   • Type - filter by voucher type (E31, E32, etc.) or leave All types.
4. Each row shows:
   • e-CF number - the type code + number (e.g. E310000000042).
   • DGII status - colored badge with the current status.
   • Reference - the document type that originated the e-CF (Invoice, Credit Note, POS Order, Return).
   • Retries - number of failed submissions (in amber if > 0).
   • Created and Last submission.
5. Click a row to open the detail. On the detail page you will see the Track ID DGII, the XML hash, the DGII response, the certificate used to sign, and the audit information.

Available actions

From each row's action menu you can:

• View detail - Opens the full e-CF page with the DGII response and traceability.
• View signed XML - Downloads the XML voucher directly, with a loading indicator while the file is prepared. The download starts immediately (previously, there were a couple of blank seconds that looked like an error). Ideal for verifying that the stored audit copy matches exactly what DGII received.
• Download Printed Representation - Generates and downloads the PDF of the Printed Representation (RI) of the e-CF on the spot, from the current signed XML. No PDFs are cached: the RI always reflects the current document, including any correction made after re-signing. Available only when the e-CF is in Accepted or Accepted with observations status. The RI includes the DGII QR code and can be printed to hand to the client on request.
• Retry submission - Re-queues the e-CF in the submission queue. Useful when the rejection was due to a timeout, a network error, or a DGII endpoint being down. The Retries counter goes up.
• Edit - Opens a dialog to modify the allowed fields before resending. Available only when the status permits it (typically Rejected or Accepted with observations). The dialog's Additional notes field is now saved and persisted: it captures the reason for the correction (for example "Client RNC corrected") and stays visible next to the user and the date of the last edit in the document detail, which enriches the audit trail for certification reviews.
• Cancel - Marks the e-CF as Cancelled. It requires a mandatory Cancellation reason. The action is permanent.
• Download XML - Downloads the signed XML exactly as it was sent to DGII, with immediate download feedback. It serves for audit, the client's file, or accounting attachments. The signed XML is kept for 10 years as a retention requirement (Ley 11-92 Art. 50 § h).

Contingency badge

When an e-CF was emitted during a contingency window due to loss of DGII connectivity, its number in the table carries a Contingency badge. This lets you identify at a glance which vouchers originated under a window without DGII connectivity, which is relevant when reviewing sales reports and when reconciling against the history in DGII's Virtual Office. The badge does not imply any problem - it only marks the document's emission context.

Cash vs. credit - what determines the payment due date

The payment term you choose when invoicing (Cash or Credit) is the authoritative signal sent to DGII, not the order's outstanding balance. In practice:

• A Cash invoice never carries a payment due date in the e-CF, even if the client has not yet paid the order balance. The voucher goes out classified as a cash payment.
• A Credit invoice must have a due date; if it is missing, emission stops before signing (see below).

Previously, a cash invoice with a pending order balance could be classified as credit by mistake and fail to emit with FechaLimitePago is required. Now the term declared on the invoice rules: a cash invoice never generates <FechaLimitePago>.

Credit invoices - the due date is mandatory

For vouchers emitted against a credit sale (payment type 2 - Credit), DGII requires the e-CF to include the payment due date in the document header. This applies to the types: E31, E32, E33, E34, E41, E44, E45, and E46.

Mosce ERP takes that date from the invoice's Due date field. If you are going to invoice a credit sale from an order, make sure to:

1. Set Credit as the payment term when invoicing the order.
2. Capture the invoice's Due date (format DD-MM-YYYY) - Mosce ERP derives it by default from the credit term configured for the client.

When the date is present, the voucher is signed and sent to DGII as <FechaLimitePago> inside the e-CF header, and DGII processes it normally.

If the credit invoice has no due date, Mosce ERP stops emission before signing and leaves the voucher in Not sent status with the message:

The credit voucher has no due date, so it cannot be signed. Set the invoice's Due date and retry.

The message is shown in the document detail. To resolve it:

1. Open the invoice that originated the e-CF.
2. Add the Due date (in format DD-MM-YYYY).
3. Return to the e-CF Documents tray and press Retry submission on the voucher's row.

This validation is local - the e-CF never reaches DGII without the date. If instead the date is present but does not match what DGII expects, DGII responds with code 1100 - "FechaLimitePago no es válido" and the document ends up Rejected. In that case check the format and resend.

Special case - E43 (Minor Expenses): E43s never include the due date, not even for credit sales; it is an exception in the DGII format for minor expenses. Mosce ERP hides it automatically for that type. For the rest of the credit types the date is mandatory. The E43 is not emitted when invoicing a sale: it is generated from its own monthly screen (see Minor Expenses).

Consumer Invoices (E32) of RD$250,000 or more - require the buyer's RNC/Cédula

DGII establishes that any Consumer Invoice (E32) whose total amount is equal to or greater than RD$250,000 must identify the buyer with their RNC or Cédula. Below that amount, the value is optional and you can invoice Final Consumer with no document; that is the normal case of a counter sale.

To keep DGII from rejecting the voucher, Mosce ERP validates this rule at the time of invoicing, only when the fiscal module is enabled:

• If you are going to invoice a sale as E32 for RD$250,000 or more and the selected client has no RNC/Cédula (for example, a generic Final Consumer), pressing Invoice shows an error message and emission is not allowed.

To resolve it you have two paths:

1. Add the buyer's RNC/Cédula in the client record and invoice again - this is the correct option when the sale genuinely exceeds the threshold and must be issued in the name of an identified buyer.
2. Use another voucher type appropriate to the operation (for example, a Fiscal Credit Invoice E31 if the buyer requires it for fiscal purposes).

When the client does have an RNC/Cédula, Mosce ERP includes it in the voucher as <RNCComprador> and DGII processes it normally. If for some reason the voucher reaches DGII without the mandatory RNC, DGII responds with a rejection for lack of buyer identification.

DGII reference: e-CF Format, section "RNC Comprador" - the electronic Consumer Invoice (type 32) with a total amount ≥ DOP$250,000.00 must identify the buyer's RNC/Cédula; below that amount the field is optional. Public documentation at dgii.gov.do.

Foreign Payment Voucher (E47) - services only

The Electronic Voucher for Foreign Payments (E47) supports the payment of Dominican-source taxable income to non-resident individuals or legal entities (foreign beneficiaries). By its nature, this voucher can only contain service lines, not goods: DGII requires that in the E47 each item be declared as a Service (<IndicadorBienoServicio> with value 2).

Mosce ERP enforces that rule at two moments:

• When creating the order. When the client has the E47 (Foreign Payment) as their default voucher, each line is fixed as "Service": the "Product" option is disabled and an explanatory note is shown. This way an E47 order cannot be built with goods.
• When emitting. If by some path an E47 order reaches invoicing with a line that is not a service, the system blocks emission with a clear message and does not consume any voucher number.

The Point of Sale does not offer the E47 as a voucher type, because its lines are always products.

The buyer of an E47 is a foreign party

The beneficiary of an E47 is a non-resident, so they carry no RNC. They are identified as a foreign party with their foreign identifier or passport number. When registering that client, use the foreign identification document type (passport / foreign identifier) and assign them the E47 as the default voucher; from then on their orders will be born with service lines and the correct voucher type.

DGII reference: Formato Comprobante Fiscal Electrónico v1.0 - the <IndicadorBienoServicio> field must be filled with value 2 (Service) when a Foreign Payment Voucher is emitted; for a foreign buyer the <RNCComprador> field is left blank and the foreign identifier is filled in. Public documentation at dgii.gov.do.

Consumer Invoices (E32) under RD$250,000 - what DGII receives

When you emit a Consumer Invoice (E32) for an amount under RD$250,000, DGII does not require web-service transmission of the full e-CF. Mosce ERP delivers only the RFCE (Summary of the Electronic Consumer Invoice) to DGII's reception service, which is transmitted automatically, and the full e-CF is stored locally for your file and for delivery to the client on request. There is no recurring manual step on your part for these vouchers: the summary travels on its own and the full one is kept.

Filter by amount range - the Amount column

The e-CF Documents tray includes an Amount column (in RD$) and an amount-range filter, useful when you handle many vouchers and need to locate those of a certain value.

• Amount column - shows the voucher total in pesos. Large amounts are abbreviated; hovering over them shows the full total.
• Amount-range filter - type a minimum amount, a maximum amount, or both (in pesos), and the list shows only the vouchers whose total falls within the range. You can combine it with the status tabs and the other filters.

Vouchers with no recorded amount. Some old rows do not have the amount saved. When the range filter is active, those vouchers are excluded from the list and the interface warns you about it. Purchases (E41) and Minor Expenses (E43) vouchers do show their amount, so they also respond to the filter.

How amounts are presented in the e-CF

Line amount - before taxes

In the electronic tax voucher, the amount of each line reflects the amount before taxes: unit price × quantity, minus any line discount. ITBIS and additional taxes (ISC, legal tip, etc.) appear aggregated in the document's totals section, not embedded in each line's price.

Line amount = Unit price × Quantity − Line discount
Line ITBIS = Line amount × ITBIS rate

In the Printed Representation handed to the client, the totals show the subtotal without tax, the total ITBIS, and the grand total in separate rows.

Global discounts

If an invoice includes a global discount (at the document level, not per line), Mosce ERP distributes it proportionally across the lines before calculating taxes. The global discount reduces the tax base of each line.

How to read the printed voucher

The Printed Representation (RI) is the printable or PDF version of the e-CF that you hand to the client or file. These are the points worth knowing how to read; the full format detail is in Printed Representation and QR.

• Exempt lines. Each exempt line carries the indicator "E" to the left of the description. It is how DGII marks what is not subject to ITBIS.
• Taxed Subtotal vs. Exempt Subtotal. The totals block separates the Taxed Subtotal (what does pay ITBIS) from the Exempt Subtotal (what does not). An exempt amount adds to the Exempt Subtotal, never to the Taxed one.
• CDT and Legal Tip. When the voucher includes them, they appear as their own lines in the totals: CDT (Contribución al Desarrollo de las Telecomunicaciones) and Legal Tip.
• Global discount or surcharge. If the voucher carries a document-level discount or surcharge, the printout shows its description, its percentage, and the amount.
• Buyer's RNC. On a Consumer Invoice (E32) equal to or greater than RD$250,000 the buyer's RNC is mandatory and is printed; below that amount it is optional (final consumer).
• Digital Signature Date. The printout labels the date and time of the signature as "Fecha de Firma Digital:".
• QR code and Security Code. They go in the lower left corner of the voucher. The QR carries the DGII verification link; the Security Code is 6 characters printed below the QR.

Special-regime (E44) and Minor Expenses (E43) vouchers correctly show their lines and their total amount in the printout, with exempt treatment where applicable.

What happens if DGII rejects a voucher

When DGII rejects an e-CF, what happens to the voucher number (eNCF) depends on the reason for the rejection. In its response DGII returns an indicator (secuenciaUtilizada) that reports whether that number can be reused or not. There are two scenarios:

1. Rejection by content or business - the number is consumed. If the rejection is due to a voucher field (an amount that does not add up, a wrong client RNC, a missing mandatory field, etc.), DGII marks the number as used: that eNCF cannot be reused. When you correct the value and retry, Mosce ERP emits the corrected voucher with the next number in the sequence. The previous number is cancelled and is not emitted again.

That is why, after correcting a content rejection, it is normal to see that the voucher went out with a different number than the original attempt. It is not an error: it is the DGII rule. A number rejected by content is considered consumed and the sequence advances. See e-CF sequences.

2. Structural or signature rejection - the same number is retried. If the rejection is due to a structural cause (invalid XML structure, invalid certificate or signature, unauthorized signer, eNCF not authorized for the issuing RNC, expired sequence, etc.), DGII marks the number as reusable: the voucher keeps the same eNCF and is retried with that number once the cause is resolved.

This behavior applies to all e-CF types, not just one type in particular. In the rejected voucher's detail you see the status and the DGII message with the reason, which is what tells you which of the two scenarios applies before retrying.

Retry a rejected submission

1. Filter by the Rejected tab.
2. Open the detail and read the DGII Response to understand the reason (invalid RNC, mismatched amount, sequence exhausted, etc.).
3. If it is a transient error (network, DGII service down), press Retry submission from the action menu.
4. If it is a data error (amount, client RNC, etc.), use Edit, correct the fields, and save. Then retry again.

Cancel an e-CF

1. In the row's action menu, choose Cancel.
2. In the dialog, write the Cancellation reason (mandatory) - briefly describe why it is being cancelled. This reason is kept in the audit.
3. Press Cancel document. The action is permanent.
4. If the voucher had already been accepted by DGII, the accounting-correct step is to also emit a Credit Note (E34) from Invoicing to reverse the operation.

Expected result

• Filterable list of all emitted e-CFs with their updated status.
• For each e-CF: Track ID DGII, DGII response, downloadable XML, and complete traceability.
• Retries visible with a count and the option to resend without recreating the document.
• Cancellations recorded with reason and audit.

Common errors

Related

• Fiscal configuration
• e-CF certificate
• e-CF sequences - why a number rejected by content advances the counter.
• Minor Expenses - the E43 voucher that groups the month's minor expenses.
• DGII reports
• Cancel and modify e-CFs - correction of e-CFs already sent to DGII.
• ITBIS and other taxes - how Mosce ERP calculates the taxes that appear in each e-CF.
• Printed Representation and QR - what the downloadable voucher PDF contains.
• Contingency and backup plans - what the contingency badge means on an e-CF.

Regulatory sources

1. DGII - Informe Técnico e-CF v1.0 §8 (page 15): the four validation statuses DGII may return when an e-CF is sent ("e-CF aceptado", "e-CF aceptado condicional", "e-CF rechazado", "e-CF en proceso") and the TrackId as the tracking identifier returned by the reception service. Available at the DGII portal.
2. DGII - Descripción Técnica de los Servicios (Reception of e-CF and Reception of RFCE): the secuenciaUtilizada parameter in the validation response - True = the sequence cannot be reused (the number is consumed), False = the sequence can be reused (rejections by certificate/signature, XML structure, unauthorized signer, unauthorized or expired eNCF, and invalid issuing RNC). Available at the DGII portal.
3. DGII - Formato Comprobante Fiscal Electrónico v1.0 (Item Detail, <IndicadorBienoServicio> field): when a Foreign Payment Voucher (type 47) is emitted the Good or Service field must be filled with value 2 (Service); for a foreign buyer the <RNCComprador> field is left blank and the Foreign Identifier is filled in. Available at the DGII portal.
4. DGII - Informe Técnico e-CF v1.0 §4.3 (Reception of RFCE, page 8): the Electronic Consumer Invoice with an amount under RD$250,000 is transmitted to DGII via the Summary of the Consumer Invoice (RFCE), not the full voucher. Available at the DGII portal.