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:

Four of these statuses translate the technical statuses DGII returns when validating: "e-CF aceptado" (Accepted), "e-CF aceptado condicional" (Conditional), "e-CF rechazado" (Rejected), and "e-CF en proceso" (Pending) - per Informe Técnico e-CF v1.0 §8 (page 15). The rest describe where the voucher stands inside Mosce ERP: whether it has not gone out yet, whether it is still waiting on an answer, or whether it has been withdrawn.

The distinctions that matter

Three pairs of statuses get confused with each other, and that is the one thing worth remembering from the table:

• Pending versus Waiting to Send. Pending has already been sent to DGII and is awaiting its verdict. Waiting to Send was signed during a DGII outage and has not left Mosce ERP yet. That contrast is all the useful information in the pair: one is already on DGII's side, the other is not yet.
• Cancelled versus Cancelled with DGII. Cancelled was withdrawn by your own decision, inside the Mosce ERP record - typically a voucher DGII never got to hold. Cancelled with DGII was acknowledged by DGII itself, through the e-NCF Annulment. A voucher DGII already accepted never passes through Cancelled: it is withdrawn with a credit note. See Cancel and modify e-CFs.
• No Response does not mean rejected. It means DGII did not answer within the query window and Mosce ERP stopped asking. The voucher may be accepted on DGII's side without that being reflected here yet - check it manually with the Track ID before assuming anything.

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 Conditional 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 Conditional). 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 in the Mosce ERP record. It requires a mandatory Cancellation reason and the action is permanent. It does not appear for a voucher DGII has already accepted (Accepted or Conditional): that one is withdrawn with a Credit Note (E34).
• 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.

Electronic delivery to the recipient

This is business-to-business logistics, not a problem with your invoice. DGII already accepted the voucher: it is issued, signed, and fiscally valid no matter what happens with this delivery. If the client's system does not respond, the only thing that failed is that specific handoff between two businesses - never the validity of the e-CF.

Besides sending every e-CF to DGII, the electronic-voucher model asks the issuer to deliver a copy of the signed voucher directly to the recipient's own system, when that recipient is also registered as an electronic receiver before DGII. Mosce ERP performs this delivery automatically as soon as DGII accepts the voucher.

Most of your clients are not yet registered as electronic receivers. Nothing changes for them: the Printed Representation you already generate satisfies the delivery obligation, exactly as it has all along.

The e-CF detail shows an Electronic delivery section with one of these states:

While a voucher has not yet been evaluated for delivery (for example, while it is still awaiting DGII's response), this section does not appear yet in the detail.

What happens if the client's system does not respond

1. Mosce ERP retries delivery with progressively longer waits - at one minute, five minutes, fifteen minutes, and so on up to 24 hours, for a total of 8 attempts.
2. If no attempt succeeds, the status becomes Not delivered. Most of the time this means the client's system did not respond in time, and retrying makes sense. In a smaller set of cases the reason will not resolve by retrying (for example, the client rejected the delivery, or requires authentication Mosce ERP does not yet support for third parties) - the detail shows which of the two applies.
3. In the meantime, and after the retries run out, the delivery obligation is covered by the Printed Representation - the same path you already use with a client who is not an electronic receiver. You can download or print it and hand it over as always.
4. When retrying can help, and you have the fiscal:manage permission, the section shows a Retry delivery button, which restarts the retry ladder as many times as needed - for example, as soon as the client confirms their system is back up. When the reason will not resolve by retrying, the button does not appear and the detail suggests contacting the client directly.

A Not delivered status never affects the voucher's standing with DGII, never changes its fiscal validity, and never blocks e-CF delivery to other clients: a down recipient's failure stays isolated to that recipient.

The same logic applies in the other direction: when you commercially approve a voucher from a supplier, that approval is also delivered to their system. See Commercial approval of received e-CFs.

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

Which receipts require identifying the buyer by RNC or Cédula

Not every receipt type accepts an anonymous buyer. Before invoicing, it helps to know which types require it, so you don't build a sale the system will reject - or that DGII would end up rejecting later, with the payment already taken.

• Always, no matter the sale amount: the Fiscal Credit Invoice (E31) and the Governmental receipt (E45) require identifying the buyer by RNC or Cédula.
• By Mosce ERP policy, even though they are ITBIS-exempt: Special Regime (E44), Export (E46), and Foreign Payment (E47) also require identifying the buyer. For E47 the buyer is a foreign party and is identified with their foreign document instead of a Dominican RNC - see The buyer of an E47 is a foreign party below.
• By amount: the Consumer Invoice (E32) only requires it at RD$250,000 or more - see the next section.

This rule applies the same way regardless of the sale path you use: invoicing an order from its own screen, or collecting at the Point of Sale. If the chosen receipt type requires identifying the buyer and the sale's client has no RNC/Cédula on file, Mosce ERP rejects the operation at the moment you invoice or collect, with a message explaining why, before taking any payment. To resolve it: add the buyer's RNC/Cédula to the client, or choose a receipt type that does accept an anonymous buyer (for example, a Consumer Invoice E32 below the threshold).

DGII reference: Formato Comprobante Fiscal Electrónico v1.0, "RNC Comprador" field - buyer identification is mandatory by receipt structure on the types that require it with no amount condition. Public documentation at the DGII e-CF portal.

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 when invoicing an order or collecting at the Point of Sale, 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 or Collect 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.

• Branch in the header. The voucher shows the branch where the sale took place, taken from the originating order or invoice - not from a single value configured by hand. See Branch Name on the e-CF Voucher for the full detail (the 20-character limit, what happens to already-issued vouchers, and which vouchers fall outside this).
• 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.

This action cancels the voucher in the Mosce ERP record: it issues no credit note and does not, on its own, send any annulment to DGII.

A voucher DGII has already accepted cannot be cancelled. If the e-CF is Accepted or Conditional, Mosce ERP does not offer the Cancel action and refuses it with the message "The DGII already accepted this document: void it with a credit note." The route is to issue a Credit Note (E34) for the full amount from the original invoice, or to cancel the order that produced it: that note is the void before DGII, not a step added on top of cancelling the voucher. The detail is in Cancel and modify e-CFs.

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.
• Branch Name on the e-CF Voucher - which branch prints on each e-CF when you have several.
• Contingency and backup plans - what the contingency badge means on an e-CF.
• Commercial approval of received e-CFs - how your commercial approval is delivered to your supplier's system.

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.10 (page 9) and §10 (page 17): the e-NCF Annulment service covers ranges of unused sequences and signed e-CFs that have not yet been sent either to DGII or to the recipient; once the voucher has been sent, corrections and annulment are carried out solely through electronic credit or debit notes. The same section states that an e-CF rejected by DGII is not considered valid and that the issuer must issue a new one and replace the one delivered to the recipient. Available at the DGII portal.
5. 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.
6. DGII - Informe Técnico e-CF v1.0 §8 (page 15): the operation model states that, following the TrackID that DGII returns in step 2, the electronic issuer must deliver the e-CF to the electronic recipient (step 3, among the "mandatory steps"); when the recipient is not electronic, that delivery is satisfied with the Printed Representation (page 16). Available at the DGII portal.
7. DGII - Descripción Técnica de los Servicios (Directory of Electronic Taxpayers): exposes the reception and commercial approval URLs each electronic taxpayer has registered, which is what makes it possible to deliver the voucher directly to their system. Available at the DGII portal.