Advance payment invoices in CFDI 4.0
April 4, 2026
The CFDI advance payment invoice (CFDI: Mexico's electronic invoice; advance payment invoice: the CFDI you issue for money received before you deliver the goods or service) is probably the most confusing flow in all of Mexican electronic invoicing. The concept itself isn't hard. The difficulty is that a single transaction can take up to four different documents: an advance payment invoice, the final CFDI, a credit note (an Egreso CFDI, type E) that reverses the advance payment, and possibly a payment complement (the complement that records each payment received against a PPD invoice; the type P CFDI that carries it is also called REP). The payment complement comes in when the final CFDI is PPD (paid in installments or later, Pago en parcialidades o diferido). I've seen development teams lose weeks trying to implement this flow correctly.
The good news is that once you understand the sequence, the pattern repeats the same way every time.
What is a CFDI advance payment invoice
An advance payment invoice in Mexico is a CFDI that covers a partial payment you receive before you deliver goods or provide a service. The SAT (Mexico's tax authority, Servicio de Administración Tributaria) needs to know you received money, but since there's no complete transaction to invoice yet, you issue a specific advance payment invoice.
The key code in the SAT catalog is 84111506 (Servicios de facturación, billing services). That's the ClaveProdServ you use for the advance payment's line item. Don't use the code of the final product or service, because you haven't delivered it yet.
Don't confuse an advance payment with a partial payment. If you already delivered the product or service and the customer pays you in installments, that's not an advance payment. That's the PPD payment method (whether the CFDI is paid in full when issued, PUE, or later or in installments, PPD; not how the customer pays) with a payment complement. An advance payment applies when the money arrives before the goods or service, or their price, has been defined. If you already agreed on both, even without a written agreement, a payment before delivery is a sale in installments, not an advance payment.
When you need to issue an advance payment invoice
These are the scenarios where it applies, as long as the goods or service, or the price, hasn't been defined yet:
- A customer pays you toward a project you haven't started yet
- You receive an upfront payment before you deliver goods
- You're paid in advance for part of a future service
- A contract calls for advance payments before the service is provided
If the money arrives and you can't invoice the goods or service yet because they, or their price, haven't been defined, you need an advance payment invoice. If they have, the payment is part of a sale in installments.
If you receive an advance payment and only issue the final invoice when you deliver, you have a tax timing mismatch. The SAT can detect uninvoiced income for the period between the advance payment and the final invoice. The advance payment invoice solves this.
The full advance payment flow
This is the flow you need to implement from start to finish:
Receive the advance payment and issue an income CFDI#
When you receive the money, issue an income CFDI (type I, the regular sales invoice) with the key 84111506. The payment method is always PUE (paid in full when the CFDI is issued, Pago en una sola exhibición): the advance payment invoice covers money you already received, and the SAT's filling guide for Anexo 20 (the SAT technical standard that defines the CFDI: its XML structure, catalogs, and validation rules) requires PUE on it.
The form of payment (how the customer paid: cash, bank transfer, card; the FormaPago key) matches how you actually received the money: 03 (Transferencia electrónica de fondos, electronic funds transfer), 01 (Efectivo, cash), and so on. The recipient's CFDI use (how the recipient will use the CFDI for tax purposes) is S01 (Sin efectos fiscales, no tax effect) or G03 (Gastos en general, general expenses), depending on the agreement.
Deliver the goods or service and issue the final CFDI#
When you finally deliver the product or provide the service, issue the final CFDI for the full amount of the transaction. This CFDI uses the actual ClaveProdServ of the goods or service, not the advance payment key.
The amount covers the full transaction, not the remainder. If the service is worth $20,000 MXN and the advance payment was $5,000 MXN, the final invoice is for $20,000 MXN.
Issue a credit note for the advance payment#
To avoid invoicing the same income twice, issue an Egreso CFDI (the credit note) for the amount of the original advance payment. Relate this Egreso to the final CFDI, which becomes its related CFDI (a CFDI this one replaces, credits, or pays, with its TipoRelacion key), using the final CFDI's UUID (folio fiscal, the unique ID the PAC assigns when it stamps a CFDI) and relationship type 07 (CFDI por aplicación de anticipo, CFDI that applies an advance payment).
This is what balances the books with the SAT: you invoiced $5,000 MXN for the advance payment + $20,000 MXN for the final CFDI = $25,000 MXN, but with the $5,000 MXN credit note, net income comes to $20,000 MXN.
The final CFDI must carry relationship type 07 to the advance payment invoice. The credit note also uses type 07, related to the final CFDI. Without these relationships, the SAT can't rebuild the flow and you could end up with discrepancies.
This flow is scheme A of the Anexo 20 filling guide, which applies the advance payment with a credit note. The guide also accepts scheme B: the final CFDI records the advance payment as a discount, so its total is the remainder, and no credit note is issued.
Advance payment invoice vs regular invoice
ClaveProdServ: 84111506 (Servicios de facturación)
CFDI type: Income (I)
When: You receive money before you deliver
Documents involved: Up to 4 (advance payment invoice, final CFDI, credit note, and a payment complement if the final CFDI is PPD)
Issuer's tax regime (régimen fiscal, the SAT category a taxpayer is registered under, such as 601 or 626): The one registered with the SAT
Note: The advance payment counts as taxable income in the month you receive it, not when you deliver the service
Common mistakes with advance payment invoices
Using the final product's ClaveProdServ on the advance payment invoice. The advance payment invoice always uses 84111506. If you use the actual product's key, the SAT reads it as if you already delivered the goods, and when you issue the final invoice your income is duplicated.
Forgetting the credit note. Without the credit note, your income in the SAT's records is the advance payment + the final CFDI. If the advance payment was $5,000 MXN and the service $20,000 MXN, the SAT sees $25,000 MXN of income when it should see $20,000 MXN. In this flow, the credit note is mandatory.
Issuing the advance payment invoice as PPD. The advance payment invoice always uses PUE, and the form of payment is the real one (transfer, cash, and so on). If the advance payment arrives in parts, issue one advance payment invoice for each part.
Not relating the documents with type 07. Relationship type 07 (CFDI por aplicación de anticipo) is what tells the SAT that these documents belong to the same flow. Without it, they're independent documents and the numbers don't add up.
How to issue a CFDI advance payment invoice with Fiscalapi
With Fiscalapi, you issue the advance payment invoice, the final CFDI, and the credit note in sequence. In the final CFDI and the credit note, you pass the related CFDIs in relatedInvoices, with relationship type 07 and their UUIDs, and the API builds the CfdiRelacionados node the SAT requires. The advance payment invoice goes without related CFDIs. Fiscalapi's GitHub repositories have working examples of income CFDIs and credit notes with related CFDIs, and the API documentation covers every field.
Frequently asked questions about advance payment invoices
The advance payment flow isn't intuitive the first time. Four documents for a single sale seems excessive, but each one has a specific tax purpose. The key is to automate the whole chain so your system issues the documents in sequence with no manual steps. See the Fiscalapi documentation for the exact fields of each CFDI type involved.