Uruguay CFE Exchange and Receipt Acknowledgments Guide

Uruguay CFE exchange and receipt acknowledgments changed on September 1, 2024 because a specific issuer-to-issuer interchange step, not Uruguay's whole e-invoicing regime, became mandatory in a narrower part of the CFE workflow. Under Uruguay Resolution DGI No. 1256/024, published through IMPO, from September 1, 2024 the designated web services became mandatory for the interchange of CFE and the corresponding receipt acknowledgments between electronic issuers when that exchange is executed through authorized providers. If you have seen both July 1, 2024 and September 1, 2024 in source material, use September 1, 2024 for this rule.

This does not replace the broader CFE framework administered by DGI. It targets the provider-mediated issuer-to-issuer interchange layer. A practical decision rule is: if your exchange between electronic issuers is executed through authorized providers, the mandatory web-service rule applies from September 1, 2024; if not, you still need to assess your flow under the broader CFE framework rather than assuming this narrower interchange rule fits your setup. For controllers, AP leads, ERP administrators, and provider-supported teams, the real task is to confirm who owns the exchange channel, how the sobre is handled, and whether acknowledgment logic is visible enough to monitor from the effective date forward.

Where Issuer-to-Issuer Interchange Fits in Uruguay's CFE Workflow

In Uruguay, issuing a CFE, one of the country's Comprobantes Fiscales Electronicos, is only one part of the operational chain. Once the document exists, there is a separate exchange layer between electronic issuers: one side has to send the CFE through the accepted interchange path, and the other side has to receive it and return the related response messages. That is the practical context for Uruguay interchange between electronic issuers. It sits after creation of the tax document, but before the workflow is truly complete from an operations and control standpoint.

A useful way to frame the Uruguay electronic issuer interchange workflow is as three distinct layers:

1. Issue the CFE. Your ERP, billing platform, or provider generates the electronic tax document correctly under the broader CFE rules.
2. Exchange the CFE. The document is transmitted from one electronic issuer to another through the interchange channel that applies to that relationship and operating model.
3. Receive follow-up messages. The receiving side sends back statuses or acknowledgments, including receipt-related responses, which become part of the control trail around delivery and processing.

The reason to separate those layers is practical: teams often treat successful issuance as the finish line. It is not. A company can generate valid CFE documents and still have a gap in Uruguay CFE exchange requirements if the issuer-to-issuer delivery layer, message handling, or acknowledgment capture is not aligned with the required interchange flow.

This is also where readers can get tripped up by older versus narrower guidance. In the broader framework commonly discussed around CFE and Resolucion DGI No. 798/2012, you will still see references to minimum admitted channels such as email for document delivery in certain contexts. The newer interchange rule discussed in this article is narrower: it focuses on the web-service execution layer for exchange between electronic issuers, especially where providers or integrated systems are handling that traffic. So the question is not just, "Can we issue CFE?" It is also, "How are CFEs and related response messages actually exchanged between issuer systems?"

For controllers, AP teams, ERP admins, and integration owners, that means the control point shifts from document creation alone to the full handoff chain. You may need to verify whether your platform merely issues the tax document, whether it also supports the required interchange between electronic issuers, and whether it stores the resulting acknowledgments in a way your finance team can monitor. If you need more background on Uruguay's broader CFE regime and document types, that overview is the right place to start, but the narrower issue here is the exchange layer that sits on top of issuance.

What an Acuse de Recibo Means in Practice

If you are asking what is an acuse de recibo in Uruguay, the practical answer is this: it is the acknowledgment message that shows the interchange step produced a trackable response. In other words, sending a CFE is not the same thing as proving the other side received it through the required channel. The acuse is the exchange-layer signal that the message reached the next step and generated a status your team can act on.

For finance and ERP teams, a Uruguay acuse de recibo CFE is useful because it confirms operational facts, not broad business conclusions. Depending on the flow, that acknowledgment can show that the document or sobre was received, that the recipient side issued a response, or that the interchange returned an acceptance or rejection type outcome at the messaging level. What you should not assume is that a receipt acknowledgment automatically settles the tax treatment, approves the invoice commercially, or closes the AP workflow. It proves something important, but narrower: the exchange itself moved and answered.

In day-to-day operations, that difference matters. The point of Uruguay CFE acuse de recibo requirements is not just formal compliance language. They give controllers, AP leads, and support teams a way to separate "sent" from "received and responded to." If no acknowledgment arrives, or if the response indicates a problem, you have an exception to investigate. If the acknowledgment does arrive, you have evidence that the interchange completed the expected step, which supports reconciliation, provider follow-up, and audit trails for disputed deliveries. Teams should also map which acknowledgments relate to the sobre itself and which relate to the individual CFE or later response messages, because those layers do not always answer the same operational question.

For a neighboring example of why acknowledgment evidence matters, how receipt acknowledgments affect invoice acceptance in Chile looks at a different regime. The rules are not identical, but it is still a useful reference point for why status evidence shapes queue management, exception handling, and supplier or customer support actions.

How the Sobre and Web-Service Standard Shape the Message Flow

The easiest way to picture the Uruguay electronic issuer interchange workflow is to separate the tax document itself from the exchange wrapper that carries it. The CFE is the fiscal document. The sobre is the exchange envelope. DGI technical materials treat those as parts of a structured interchange model, alongside the response message that comes back after transmission.

For a finance or controller audience, the key point is not how to build XML by hand. It is understanding what the Uruguay CFE sobre standard is doing in operational terms. Your issuer, ERP, or authorized provider does not just send an invoice. It packages the transmitted CFE inside the sobre structure DGI expects, routes it through the agreed exchange method, and then receives the corresponding acknowledgment message that tells the sender whether the handoff was accepted, rejected, or needs attention.

In practice, the message flow looks like this:

1. Your issuing side generates the CFE.
2. The sending system or provider places that CFE inside the sobre, adding the header and structural elements the exchange format requires.
3. The message is sent through the designated Uruguay CFE web services model when the interchange is executed through authorized providers.
4. The receiving side validates what arrived at the message level, not just the commercial content of the invoice.
5. The receiving side returns the related acknowledgment or response message, which becomes part of the control trail for AP, finance operations, and support teams.

Here is what that looks like in practice: one issuer creates the CFE, its provider packages the document inside the sobre, and the message is transmitted through the required service path to the receiving issuer or that issuer's provider. The receiving side then sends back evidence that the exchange step was received and processed. One signal may relate to the envelope-level handoff, while later responses may relate to the individual CFE or the next stage in the chain. If one of those expected signals is missing or rejected, finance and ERP teams have an exception to investigate rather than assuming the invoice simply "went through."

That is why the technical assets matter even if your team never opens them. XML defines the message content, XSD files define what valid structure and field patterns look like, and WSDL materials define how the web-service calls are supposed to be made. Your provider or ERP integrator works directly with those artifacts. Finance teams mainly need to know what they govern: who can send, what format is accepted, how the receiver answers, and where a mismatch will surface.

When something breaks in this flow, it usually breaks at the message boundary. The CFE may be commercially correct, but the sobre version may be wrong, the receiver identifier may not match, the expected schema may differ from what the sender transmitted, or the response message may not come back as expected. That is why message-level validation and status handling matter so much. If you want another article on status evidence, how validation and response statuses work in Peru's e-invoicing flow shows a different Latin American model. The useful takeaway is not that Peru and Uruguay operate the same way, but that response messages are often the control point operations teams watch.

For controllers and AP leaders, the key takeaway is that the sobre is not background plumbing. It is the structured container that makes Uruguay CFE web services workable between electronic issuers, and the acknowledgment flow is the evidence that the transmission reached the other side in a usable form.

---

What Finance, AP, ERP, and Provider-Supported Teams Should Verify

A useful readiness review for Uruguay CFE exchange and receipt acknowledgments should answer one operational question: can your team prove the document moved through the required issuer-to-issuer path, through the web-service-supported flow, with the right receipt statuses visible to the people who need to act on them?

Start with the ownership map. Issuing a CFE is not the same as having a compliant issuer-to-issuer interchange and acknowledgment loop. Your finance or ERP owner should be able to show who actually executes the exchange between electronic issuers, whether that step sits with an authorized provider or a provider-supported ERP flow, and where responsibility changes hands if something fails.

Use this checklist:

1. Confirm scope and handoff. Ask whether issuer-to-issuer interchange is executed through authorized providers, where your ERP or billing platform hands off to that provider-supported flow, and which team owns retries and status visibility.

2. Verify the effective date used for sign-off. Some internal notes, project plans, or provider documents may still refer to July 1, 2024. For operational acceptance, controls review, and incident escalation, use September 1, 2024 as the effective date your workflow should be measured against.

3. Map the full message flow and status layers. Ask your provider or integration lead to diagram issuance, sobre creation, transmission, receipt, and which acknowledgments relate to the sobre versus the individual CFE or later response messages. If they cannot show the sequence clearly, you do not have enough evidence that your Uruguay CFE exchange requirements are being met in production.

4. Confirm how the sobre is created, validated, and preserved. Your team should know where the sobre is generated, what system populates it, what happens if it is malformed or rejected, and whether a retrievable record is kept for audit and troubleshooting. If AP or finance cannot trace the sobre back to the business document and transmission event, investigations will stall.

5. Define exception ownership and test rejection handling. A compliant flow still fails operationally if no one owns rejected messages, missing acknowledgments, or timing gaps. Agree who watches dashboards, who receives alerts, who reprocesses failures, and what evidence exists when the receiving side does not acknowledge or returns a rejection your ERP does not map cleanly.

6. Check auditability end to end. A finance controller should be able to ask for one document and get the issuance record, the transmission event, the sobre-related evidence, the receipt acknowledgment status, and the exception history if anything went wrong.

When you speak with a provider or internal integration lead, bring specific questions, not broad requests. Ask who owns message flow orchestration, where status retrieval happens, how rejected or missing acknowledgments are surfaced, how often statuses are refreshed, what identifiers link business documents to interchange events, and what records can be exported for audit or dispute review.

The implementation priorities are straightforward: first confirm the correct post-September 1, 2024 flow, then validate sobre handling, then make sure acknowledgment statuses are captured in a way finance and AP can actually use, and finally assign named owners for monitoring and exception resolution.