Mexico Complemento de Pago: Deadline, PPD, and PUE

Mexico Complemento de Pago is the payment receipt complement used when a CFDI 4.0 invoice is issued on credit or in installments under PPD rather than being fully settled at issuance under PUE. In practice, that means the original invoice can exist before cash is received, but each later payment still has to be documented through a separate Complemento para recepcion de pagos, also called REP 2.0. As SAT's Rule 2.7.1.32 on payment complements explains, taxpayers may issue one complement per payment or one monthly complement covering multiple payments to the same recipient, but it must be issued no later than the fifth calendar day of the following month.

That timing rule matters because the REP is not a second invoice. It is a CFDI document that records receipt of payment for an invoice that was already issued. If an invoice was genuinely paid in full when it was created, the supplier can use PUE and no payment receipt complement is needed. If payment will arrive later, or in several installments, the workflow changes: the original CFDI is issued first, then each payment event has to be documented through its own linked REP.

For finance teams, the practical question is not just "what is the rule?" but "what type of workflow am I creating when I pick the payment method on the invoice?" Once an invoice moves into a deferred-payment path, the business now has to track cash receipt dates, invoice references, and balance changes with enough precision to support compliance and audit review.

Mexico uses this approach because IVA is tracked on a cash basis in these scenarios. SAT needs visibility into when the money was actually received, not only when the invoice was generated. That is why the payment complement sits at the intersection of tax compliance and finance operations. This guide focuses on that operational reality rather than on ERP-specific screen paths.

PPD vs PUE and the Correction Path if Cash Does Not Arrive

The most important decision is made on the original CFDI. PUE applies when the invoice is fully settled at issuance. PPD applies when payment will be deferred or collected in installments. That choice is not cosmetic. It determines whether the later cash receipt can be documented through a REP without reopening the original invoicing decision.

For AP and AR teams, the rule is easiest to manage if they treat PUE as a true same-settlement scenario and PPD as the default whenever credit terms, staged payments, or timing uncertainty exist. A supplier that issues a PUE invoice and then discovers that cash did not arrive within the month of issuance creates rework. In practice, the team usually has to correct the document flow by canceling and reissuing the CFDI with PPD so later payments can be documented properly through the payment complement process.

This is where many English-language explainers stop too early. The hard part is not memorizing the acronyms. The hard part is recognizing that the payment-method code on the invoice controls the rest of the compliance path. Once the wrong code is used, accounting teams may need to revisit the original invoice, coordinate with the issuer's PAC or ERP process, and make sure the downstream balances still reconcile cleanly.

If you need the bigger picture around invoice issuance, cancellation, and document sequencing, it helps to review Mexico's broader CFDI 4.0 invoicing framework and SAT document flow. The key point for this article is narrower: choosing between PPD and PUE is really choosing whether a later payment event will require its own linked CFDI record.

How the Payment Complement Lifecycle Works From Invoice to Final Settlement

The cleanest way to understand the rule is to map the lifecycle in order.

1. Issue the original invoice as PPD. The CFDI establishes the sale, the counterparty, and the amount due, but it does not prove payment has been received.
2. Receive the first payment later. That payment triggers a REP that references the original CFDI UUID instead of replacing it.
3. Record balance movement. The complement should reflect the prior balance, the amount just paid, and the remaining balance after that payment event.
4. Repeat for later installments until the invoice is cleared. Each partial payment becomes another linked event in the audit trail.

That is why Mexico installment payment CFDI workflows create more tracking work than a single invoice-plus-payment entry in a ledger. The invoice is the starting point, but the compliance record grows as payments arrive. For Mexico partial payment invoice tracking, the critical control is not just saving PDFs. It is preserving the relationship between the invoice, the payment event, and the running balance across the entire sequence.

Partial payment numbering matters for the same reason. If a customer pays in three tranches, the finance team needs to know which payment is first, second, and final, how much balance existed before each one, and whether the outstanding amount after each REP still matches the commercial record in the ERP or accounting system. A UUID reference without disciplined balance tracking does not solve the reconciliation problem.

SAT's monthly option can reduce document volume in some cases because one complement may cover multiple payments to the same recipient during the month. But it does not remove the need for transaction-level discipline. Teams still need to identify which payment cleared which invoice balance, especially when foreign currency, deductions, short payments, or multiple open invoices are involved.

What Data a REP Must Carry to Be Useful in an Audit

A REP is only as useful as the data inside it. Finance teams should expect to validate several categories of information rather than treating the complement as a black-box XML export.

• Payment event details: payment date, payment method, currency, and exchange-rate information where relevant.
• Linked-document references: the original invoice UUID and the fields that show which CFDI is being settled.
• Balance tracking: prior balance, amount paid in the current event, and remaining balance after payment.
• Tax context: the fields needed to reflect tax treatment and the tax object attached to the linked document set.
• Bank or account details when applicable: the payment record often needs to align with banking evidence and internal cash-application records.

Those data points matter because the structure is driven by SAT's technical schema under Anexo 20. A PAC or ERP may generate the file, but the real control activity sits with the finance team that reviews whether the exported values are complete and coherent. If the wrong UUID is linked, the exchange-rate field is missing, or the remaining balance does not tie back to the ledger, the XML may exist while the audit trail is still weak.

This is also where supporting documentation becomes important. The REP proves a payment event was reported, but teams often still need remittance details, bank evidence, or internal settlement notes to explain why a payment was applied a certain way. That is why understanding how remittance advice supports payment reconciliation and proof of payment can make the complement workflow easier to defend during close or review.

If you are asking how to issue REP CFDI correctly, the practical answer is to verify the data before and after issuance: confirm the linked invoice reference, confirm the payment amount against the bank movement, confirm the remaining balance after the payment, and confirm that any foreign-currency or tax-related fields match the underlying transaction facts.

Why REP Turns Compliance Into an Invoice-to-Payment Matching Problem

The distinctive burden of REP is that every payment becomes another document event that has to be tied back to the original invoice. That turns compliance into an invoice-to-payment matching problem for teams handling Mexico invoices, not just a filing problem. A finance team now has to match the original CFDI, the payment record, the updated balance, and the supporting evidence for each settlement step. That same discipline shows up in other Latin American frameworks, including Colombia's RADIAN event ledger for invoice acceptance, endorsement, and factoring, where downstream invoice events also determine legal and financing outcomes.

In real workflows, the failure points are predictable. One report may hold the invoice UUID, another may hold the bank transaction, and a third spreadsheet may hold the running balance after each customer payment. If one value is transposed, if proof of payment is stored separately, or if a partial payment is posted against the wrong open item, the team can still have a formally issued REP but a weak reconciliation trail. The controls described in invoice matching controls for linking payments back to original invoices become especially important when one invoice can generate several downstream payment events.

This is the gap many top-ranking explainers miss. They tell you that a complement is required, but they do not show why the rule creates ongoing operational work for AP and AR teams. The real challenge is assembling a traceable chain from the original invoice to each payment, then keeping balances synchronized across ERP records, bank records, and the documents finance will actually review during close.

Teams that want to automate invoice and payment data extraction usually care less about producing another XML file and more about building a reliable data bridge between invoices, payments, and evidence. For example, Invoice Data Extraction can pull structured fields from invoices, bank statements, vendor statements, and related finance documents into XLSX, CSV, or JSON outputs, with each output row linked back to the source file and page. That does not replace SAT issuance rules, but it can reduce the spreadsheet cleanup that sits around REP review and matching.

Seen that way, the payment complement is a document-control problem as much as a tax rule. The more deferred payments and installments you handle, the more valuable it becomes to standardize how invoice identifiers, payment references, balances, and proof-of-payment data are captured before month-end pressure turns small mismatches into open exceptions.

A Working Checklist for Staying Compliant With Complemento de Pago

Mexico Complemento de Pago requirements are manageable when the workflow is controlled at the document-chain level rather than treated as a one-off filing task. A practical checklist looks like this:

• Decide at invoice issuance whether the transaction is truly PUE or should be coded as PPD.
• Track the fifth calendar day of the following month as the working deadline for the payment complement.
• For every later payment, confirm the original CFDI reference, the payment amount, the prior balance, and the remaining balance.
• If several payments apply to the same recipient, decide carefully whether the monthly option will improve control or just compress several reconciliation tasks into one document.
• Keep payment evidence, remittance details, and bank records organized so the REP can be explained later.
• Review exceptions quickly when a PUE invoice was not actually settled within the month of issuance, because the correction path often starts with the original CFDI.

The article's core lesson is that REP compliance depends on traceability. If your team can follow the chain from the original invoice to each payment event and supporting record, the SAT requirement becomes far easier to manage. If that chain breaks, the problem is usually not the XML alone. It is the missing connection between invoicing, cash application, and audit-ready evidence.