Voucher inbox

Incoming e-CF inbox: how to decide Accept / Reject / Partial Acceptance on the vouchers your suppliers issue to you.

The Voucher inbox is where the e-CF that your suppliers issue in your name appear. When an electronic issuer invoices you, the DGII routes that XML to a public URL that Mosce ERP exposes, persists it, returns a signed acknowledgment (ARECF), and leaves it ready for you to make the commercial decision: Accept, Reject or Partial Acceptance. That decision is signed in an ACECF and sent to the DGII; once sent, it is not reversed from Mosce ERP.

Reading time: ~7 min

When to use this

You received an e-CF from a supplier and need to decide whether to accept it or not.
You want to see the history of vouchers that came in under your name and the status of each commercial decision.
Your accountant asks when a specific e-CF from a supplier arrived.
You received an e-CF that is not for you (wrong RNC) and you want to understand what to do.
You want to understand the difference between the technical acknowledgment (ARECF) and the commercial decision (ACECF).

Before you start

The Fiscal module is active and your role includes fiscal:read (to view the inbox) or fiscal:inbound:decide (to make decisions). The tenant OWNERs have both permissions implicitly.
Mosce ERP is registered as an electronic receiver before the DGII and the tenant's public URLs are registered in the taxpayer's Virtual Office. See DGII URLs and certification portal.
There are incoming e-CF to review. The inbox starts empty until the first one arrives.

How e-CF reach Mosce ERP

When an issuer invoices you, their system (Mosce ERP or another) sends the signed XML to the public reception URL that your RNC has registered with the DGII (see DGII URLs portal). Mosce ERP:

Receives the XML in multipart/form-data format.
Identifies your organization by the <RNCComprador> in the XML - the same public URL serves multiple organizations and the routing is decided by the RNC inside the document.
Verifies the digital signature with the issuer's public certificate.
Validates the XML against the canonical DGII XSD of the corresponding type.
Persists the voucher in its internal storage.
Builds and signs an Acknowledgment of Receipt (ARECF) with your organization's certificate.
Returns the ARECF in the HTTP response (synchronous, within 10 seconds).
Updates the Inbox in real time so you see the new voucher without having to reload.

The ARECF is technical: it confirms that you received the voucher and that it passed the signature and schema validations. It is not a commercial acceptance - that decision is made by you in the inbox.

The Inbox table

Availability. The Inbox screen and the decision dialogs are already in the UI. The list fills up with received vouchers as the inbound integration becomes fully active; if you open the Inbox and it appears empty even though you know you received an e-CF, contact support to verify the routing of your RNC.

Open Fiscal → Inbox from the side menu. The screen requires the Fiscal module to be enabled for your organization and your role to include the fiscal:inbound:decide permission (or that you are OWNER). If either is missing, you see a permission-denied screen with a button to return to Fiscal.

The table shows one row per received voucher with the following columns:

Column	Content
Sender	Issuer's RNC + legal name (if we know it from the DGII directory; if not, "Unknown issuer").
e-CF	Voucher number, 13 characters (e.g. `E310000123456`).
Received	Date and time when the `/fe/recepcion/api/ecf` URL received the XML.
Approval	Badge with the commercial decision status: Pending, Accepted, Rejected or Partial Acceptance.
Decided	Date and time when the decision was sent to the DGII. Empty while Pending.
Actions	Accept, Partial Acceptance and Reject buttons - only visible for rows in Pending status and only if you have `fiscal:inbound:decide`.

The commercial decision - Accept, Reject or Partial Acceptance

When you receive an e-CF from a supplier, the DGII expects you to make a commercial decision about the operation the voucher backs. That decision materializes in an XML called ACECF (e-CF Commercial Acknowledgment) that Mosce ERP signs with your certificate and POSTs to the DGII. The decision is recorded in the DGII and replicated in Mosce ERP; the voucher's commercial approval status summary reflects the most recent decision.

When to choose each one

Decision	When to choose it	Effect
Accept	The operation is correct - you received what was invoiced, the amount and taxes match, and you will use the voucher to support cost, expense, or fiscal credit.	Signed ACECF with `<Estado>` accepted is sent to the DGII. The approval status becomes Accepted.
Partial Acceptance	You received part of what was invoiced or there are differences but you want to accept what does correspond. The reason is optional but recommended.	Signed ACECF with `<Estado>` partial is sent to the DGII. The status becomes Partial Acceptance.
Reject	The voucher is incorrect, you did not receive the good/service, there is an error in data, amounts or taxes. The reason is required.	Signed ACECF with `<Estado>` rejected is sent to the DGII. The status becomes Rejected.

UI flow

Accept - confirm with window.confirm (no heavy modal dialog) and fires the POST immediately. The row updates as soon as the OK arrives.
Partial Acceptance - opens a dialog with an optional Reason field (up to 500 characters). You confirm with Partial Acceptance and the decision is sent signed.
Reject - opens the same dialog but with the reason required. If you leave the field empty, the confirm button shows a toast with the message "Reason required" and the decision is not sent.

When you confirm any of the three, Mosce ERP:

Builds the ACECF with your reason (if any), the issuer's RNC, the original e-CF, and the corresponding <Estado>.
Signs it with your organization's certificate (platform or own).
Persists the decision with a unique key that guarantees natural idempotency: a decision already sent cannot be duplicated.
Sends it to the DGII asynchronously so as not to block the UI.
Updates the voucher's commercial approval summary to reflect the most recent decision.

Idempotency and why the decision is not reversed from Mosce ERP

The uniqueness of the decision per voucher is deliberate. Once the decision has been sent to the DGII, it cannot be overwritten from Mosce ERP. If you try to decide a voucher that already has a sent decision, the UI rejects the action with a clear message and does not allow reopening the dialog.

This behavior is regulatory, not a product choice: the DGII treats the ACECF as a signed declaration by the receiver. Reversing it requires the operation to be cancelled through another circuit (typically the issuer issues a Credit Note - E34 - to reverse the operation, and you process it in turn as another inbound). It is not something a button in Mosce ERP can undo because the decision is already in the DGII.

If you think you pressed the wrong button, contact the issuer immediately to coordinate the correction through the appropriate accounting channel.

Permissions and audit

fiscal:read - required to view the inbox screen and the voucher table.
fiscal:inbound:decide - required for the Accept, Partial Acceptance and Reject buttons. Without it, the screen shows the list but the actions are hidden.
Members with the tenant OWNER role have both permissions implicitly - they do not need explicit assignment.

Each decision is recorded with its timestamp and the signed ACECF is kept in private storage for later DGII audits. The reason entered for Reject or Partial Acceptance is persisted verbatim - write something actionable, not "error". That reason may appear in DGII responses and in commercial disputes.

Common errors

Symptom	Likely cause	Solution
I received an e-CF that is not for me	The issuer wrote the wrong RNC in the XML	Reject the voucher with a clear reason ("Recipient RNC does not correspond to this entity"); the issuer must issue a Credit Note and reissue
The sender RNC does not appear with a legal name	The issuer has not yet been indexed in the DGII directory sync	The name appears as "Unknown issuer" until the directory entry is synced
The decision buttons are disabled even though the row is Pending	You lack the `fiscal:inbound:decide` permission	Ask the tenant administrator to update your permissions or your role
I pressed Accept and want to undo it	The decision already went to the DGII and is not reversible from Mosce ERP	Contact the issuer; if the operation must be reversed, the issuer must issue a Credit Note (E34) which you then process as another inbound
The inbox is empty even though I know a supplier invoiced me	Your tenant's public URL is not correctly registered in DGII OFV, or the issuer sent to a different URL	Review DGII URLs and certification portal and confirm the registered URL with your issuer
Partial Acceptance appears but I do not remember what I decided	Inspect the Decided column and open the voucher detail to see the saved reason	The persisted reason is the one that was sent to the DGII in the ACECF; consult it as evidence of the decision

Expected result

A real-time list of the e-CF your suppliers issue to you.
Each voucher with a clear commercial approval status.
Decisions made with a full audit trail: who decided, when, with what reason.
A signed and persisted ACECF for each sent decision, idempotent per voucher.
Complete traceability before the DGII in a later audit.

Last updated: 2026-05-03

Regulatory sources

DGII - Formato Aprobación Comercial (ACECF): defines the structure of the Electronic Commercial Acknowledgment, including the <Estado> field with its three admitted values (accepted, rejected, partial acceptance). Available on the DGII portal.
Decreto 587-24 and Norma General 01-2020: regulatory basis for the obligation to issue an ACECF, the irreversible nature of the decision, and the fiscal traceability of the received voucher.

Voucher inbox

On this page