CFDI form of payment: SAT codes explained
April 4, 2026
If you've ever stared at the dropdown for the form of payment (how the customer paid: cash, bank transfer, card; the FormaPago key) in your invoicing system and hesitated between 03 and 04, or, worse, put 99 on an invoice marked PUE (paid in full when the CFDI is issued, Pago en una sola exhibición) because "you have to put something," this post is for you. The CFDI form of payment (CFDI: Mexico's electronic invoice) is one of the required fields that causes the most errors in production. The field itself is simple. The trouble is that the SAT (Mexico's tax authority, Servicio de Administración Tributaria) catalog has more than 20 keys, several of them sound alike, and the rules for when to use each one aren't always obvious.
What is the CFDI form of payment
The form of payment is the CFDI field that says what means was used, or will be used, to pay for the transaction. Bank transfer, cash, credit card, check, electronic wallet. Each means has a two-digit code that the SAT assigns in the c_FormaPago catalog.
In the CFDI 4.0 XML, this field is called FormaPago and it's an attribute of the Comprobante node. It's required on income CFDIs (type I, the regular sales invoice) and on credit notes (an Egreso CFDI, type E). On a payment CFDI (type P), the form of payment doesn't go on the main node. It goes inside the payment complement (the complement that records each payment received against a PPD invoice; the type P CFDI that carries it is also called REP), in the Pago node.
Here's what a lot of people mix up: the form of payment doesn't describe when you get paid. That's the payment method (whether the CFDI is paid in full when issued, PUE, or later or in installments, PPD; not how the customer pays). It doesn't describe what for either: that's the CFDI use (how the recipient will use the CFDI for tax purposes). The form of payment describes only the means by which the money changes hands.
The form of payment must match the real transaction. If the customer paid by transfer and you put credit card, the CFDI goes through stamping (the certification by a SAT-authorized provider that makes a CFDI valid) without a problem, because the PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs) doesn't check the real means of payment. But the SAT can spot the inconsistency when it cross-checks data with the banks, and that can lead to findings in an audit.
Full SAT catalog of form of payment codes
In Mexico, this is the forma de pago SAT catalog: c_FormaPago, the official list the SAT keeps with every valid key. Here's the full catalog of current form of payment codes.
| SAT code | Description | Bancarizado (through the banking system) |
|---|---|---|
| 01 | Efectivo (cash) | No |
| 02 | Cheque nominativo (check payable to a named payee) | Yes |
| 03 | Transferencia electrónica de fondos (electronic funds transfer) | Yes |
| 04 | Tarjeta de crédito (credit card) | Yes |
| 05 | Monedero electrónico (electronic wallet) | Yes |
| 06 | Dinero electrónico (electronic money) | Yes |
| 08 | Vales de despensa (grocery vouchers) | No |
| 12 | Dación en pago (payment in kind) | No |
| 13 | Pago por subrogación (payment by subrogation) | No |
| 14 | Pago por consignación (payment deposited with a court or authority) | No |
| 15 | Condonación (debt forgiveness) | No |
| 17 | Compensación (offset) | No |
| 23 | Novación (novation) | No |
| 24 | Confusión (merger of debtor and creditor) | No |
| 25 | Remisión de deuda (debt remission) | No |
| 26 | Prescripción o caducidad (statute of limitations or expiration) | No |
| 27 | A satisfacción del acreedor (to the creditor's satisfaction) | No |
| 28 | Tarjeta de débito (debit card) | Yes |
| 29 | Tarjeta de servicios (service card) | Yes |
| 30 | Aplicación de anticipos (application of advance payments) | No |
| 31 | Intermediario pagos (payment intermediary) | No |
| 99 | Por definir (to be defined) | Optional |
Key 03 is one of the most common forms of payment in Mexico. If your customer paid you through SPEI (Mexico's interbank electronic payment system) or an interbank transfer, this is the right key. Key 99 (Por definir, to be defined) is valid only with payment method PPD (paid in installments or later, Pago en parcialidades o diferido), never with PUE.
The Bancarizado column matters for deductibility: under the Income Tax Law (LISR, Ley del Impuesto sobre la Renta), payments over $2,000 MXN must go through the banking system for the expense to be deductible (Article 27, Section III, and Article 147, Section IV LISR). The difference between 04 (credit) and 28 (debit) also matters; in e-commerce, the payment processor usually tells you the card type.
Form of payment vs payment method: the real difference
These two fields show up together in the CFDI and get confused all the time (in Spanish, it's the classic forma de pago vs método de pago question). The difference is simple, but critical.
Form of payment: the how
It answers the question: what means did the customer use to pay? Transfer, cash, card, check. It's the financial instrument used to move the money.
XML field: FormaPago
Example: 03 (electronic transfer)
Catalog: c_FormaPago, with more than 20 keys
Payment method: the when
It answers the question: have you been paid already, or will you be paid later? It has only two possible values.
XML field: MetodoPago
PUE: already paid, or pays within the same monthPPD: will pay later
The payment method determines whether you need to issue a payment complement later.
The rule that ties both fields together is this: if the payment method is PUE, the form of payment must be the real one (01, 03, 04, 28, and so on). If the payment method is PPD, the form of payment is always 99 (Por definir), because when you invoice, you don't know what means the customer will use to pay. The Spanish-language PUE vs PPD guide covers the payment method in depth.
Never use key 99 (Por definir) on an invoice with payment method PUE. The PAC accepts it, because the SAT's validation rules don't cover that combination, but it goes against the SAT's CFDI filling guide, which reserves 99 for invoices that aren't paid when you issue them. If you've already been paid, you should know how you were paid.
The 5 forms of payment that cover most cases
If you run a business in Mexico, you probably need only these five keys. The rest of the catalog exists for special situations.
| Key | When to use it | Real example |
|---|---|---|
| 01 | The customer paid with bills or coins | Brick-and-mortar store, restaurant, auto repair shop |
| 03 | The customer made a SPEI or interbank transfer | B2B payments, collections from corporate customers |
| 04 | The customer paid with a credit card | E-commerce, point-of-sale terminal |
| 28 | The customer paid with a debit card | Point-of-sale terminal, online payments |
| 99 | You don't know yet how they'll pay (PPD only) | Sales on credit, invoices with 30-day terms |
If your point-of-sale system or payment gateway tells you the means of payment, map those values to the SAT keys automatically. That way the operator doesn't have to choose by hand, and you cut down on errors. Fiscalapi takes the code directly in the paymentFormCode field.
Common form of payment mistakes
After reviewing hundreds of integrations with the API, these are the mistakes that show up again and again.
The form of payment in the CFDI 4.0 XML
In the CFDI XML, the form of payment is the FormaPago attribute of the root Comprobante node. On a PUE invoice, this attribute carries the real form of payment (for example, FormaPago="03" for a transfer). On a PPD invoice, it's always FormaPago="99".
In the payment complement, the field is called FormaDePagoP (with a "P" at the end), not FormaPago. It's a small detail that has broken more than one integration in production. The Fiscalapi documentation covers the full XML structure with examples for each scenario.
How to automate the form of payment with Fiscalapi
With Fiscalapi, you send the form of payment code in the paymentFormCode field. On income CFDIs and credit notes, the API checks that the code exists in the SAT catalog and returns an error before stamping if it doesn't. The combination with the payment method is checked at stamping: with PPD, any key other than 99 is rejected (CFDI40105). The SAT's validation rules don't cover the reverse case, 99 with PUE, so catching that one is up to your system.
Fiscalapi also exposes the full form of payment catalog through its catalogs API. You can query it programmatically to populate dropdowns in your interface instead of hardcoding the keys. That way, when the SAT updates the catalog, your system picks up the change automatically.
See the Fiscalapi documentation for the full field reference, the SDKs for .NET, Node.js, Python, PHP, and Java, and the code examples on GitHub for working implementations you can try in the test environment (test.fiscalapi.com) at no cost.
Special cases you should know
There are situations where the form of payment isn't as simple as choosing between cash and transfer.
Payments with more than one means. If a customer pays part by credit card and part in cash, the CFDI still carries a single form of payment. The SAT's CFDI filling guide covers this case: record the form of payment that settles the largest share of the payment, 04 if the card amount is larger or 01 if the cash amount is. If both amounts are the same, as in a 50/50 split, you choose one of them.
Payments through digital platforms. If you collect through Mercado Pago, PayPal, Stripe, or any other intermediary, the form of payment depends on how you received the money. If the intermediary deposits the money to you through SPEI, the form of payment is 03. If the customer paid by card through the platform, you can use 04 or 28, whichever applies. Key 31 (Intermediario pagos, payment intermediary) also exists, but the SAT's CFDI filling guide doesn't say when to use it; check with your accountant.
Advance payments. When you receive an advance payment, the advance payment invoice (the CFDI you issue for money received before you deliver the goods or service) carries the real form of payment of the advance (for example, 03 if it was a transfer). When you issue the final CFDI, you apply the advance payment with a credit note, and that credit note carries form of payment 30 (Aplicación de anticipos). That flow has its own logic and takes three CFDIs: the advance payment invoice, the final CFDI, and the credit note.
Frequently asked questions about the form of payment
The form of payment isn't a decorative field
Every CFDI field exists for a tax reason. The form of payment tells the SAT how money moves in the formal economy. When the form of payment on your invoices matches the bank movements the SAT already has on record, your business passes the automatic cross-checks without friction. When it doesn't match, alerts show up.
If you're building or maintaining an invoicing system, automate the form of payment from your payment gateway or your point-of-sale terminal. Don't let a human operator pick from 22 keys by hand every time they issue an invoice. The Fiscalapi API checks the form of payment code against the SAT catalog before stamping and returns a descriptive error if the key isn't valid. Whether the key matches how the customer paid is something only your system knows. It's better for your system to catch that error before stamping than for the SAT to find it six months later in an audit.