Skip to main content

​
Introduction

The CFDI (Comprobante Fiscal Digital por Internet) is the standardized electronic invoicing format in Mexico, managed by the country’s tax authority, the SAT (Servicio de Administración Tributaria). This system ensures that all fiscal documents are digitally generated, validated, and reported to SAT in compliance with national tax laws. In this guide you’ll learn how to issue documents — invoices, credit notes, and payment receipts (comprobantes de pago) — in a supplier’s name using the SAT Mexico app. For importing received invoices, see the companion guide: Mexico: Receiving invoices.

​
Prerequisites

To issue invoices in Mexico via the SAT, you will need:
  • A registered supplier: follow the CFDI supplier registration guide to connect the SAT Mexico app and register the supplier’s CSD certificate with the PAC before issuing.
  • Customer Information:
    • Name
    • Taxpayer ID (RFC - Registro Federal de Contribuyentes)
    • Address
    • Fiscal regime code (as defined by SAT)
    • CFDI use code (Código de uso CFDI)
  • Line items:
    • Quantity, unit price, and applicable tax rates
    • SAT product/service code (Clave Producto-Servicio)
  • Additional requirements
    • Selected invoice series
    • Place of issue code (Lugar de expedición)

​
Setup

Configure your Invopop workspace for CFDI invoicing by following these steps in the Invopop Console:
These instructions apply to both the sandbox and live environments. The SAT Mexico app must already be connected and configured — this is covered in the supplier registration guide.
Prepare a separate workflow for each document type you plan to issue: one for invoices, and one for payment receipts (comprobantes de pago).
1

Set up the SAT issue invoice workflow

SAT issue invoice workflow

Issue a CFDI invoice through SAT.
2

Set up the SAT issue payment workflow

You can skip this step if you don’t plan to issue payment receipts (comprobantes de pago) against PPD invoices.

SAT issue payment workflow

Issue a CFDI de pago (REP) through SAT.

​
Send a document

You can complete this process through the Invopop Console or the API. We’ll walk through it using the Console, but don’t worry, the steps are nearly identical for the API. We’ll add notes along the way to clarify any differences.
The following examples are of partial GOBL documents you can copy and paste directly into the Invopop Console or store via the API as silo entries. GOBL Invoices sent to the SAT require the following properties in order to perform the correct normalization and validation steps. Invopop will try to assign these automatically, but we recommend defining them explicitly before upload:
This main type of invoice is a standard B2B invoice from a Mexican supplier to another Mexican customer.Notice:
  • we’ve added the mx-cfdi-v4 addon, this ensures the document will be validated using the CFDI v4 rules built into the GOBL library,
  • extensions (ext) fields have been used in multiple locations for fields whose values cannot be determined any other way,
  • VAT will be applied at the standard rate, the percentage will be set automatically, and,
  • there are no totals nor calculations, all of these will be made automatically when uploading.
This invoice is used when the issuer (supplier) bills the customer on behalf of another taxpayer who is the real seller — for example consignment sales. The third party is identified on each line in the seller object (RFC, fiscal regime, address), while supplier remains the party issuing the CFDI.Notice:
  • the line seller carries the third party’s tax identity and regime so SAT can relate the CFDI to cuenta de terceros rules,
  • the mx-cfdi-v4 addon validates extensions on supplier, customer, and line seller,
  • the minimal tax.ext only needs the place of issue; gobl build adds document type and payment method (PPD in the built example) like other B2B invoices,
  • there are no totals in the minimal version; upload or gobl build will compute IVA and totals, and,
  • the built example shows a consignment-style line (Venta en consignación) with full tax breakdown.
This is a standard B2C invoice from a Mexican supplier to a Mexican physical person with tax details, but no specific tax declaration requirements. This would be for a larger sale when the “Simplified” and “Global invoice” do not apply.In addition to the observations for regular B2B invoices, note in the customer:
  • the presence of an RFC in the same format as for companies, and,
  • the mx-cfdi-fiscal-regime and mx-cfdi-use extensions have been set to 616 and S01 respectively reflecting that the customer is not subject to tax.
It is important in Mexico to ensure the correct Fiscal Regime and CFDI Use codes are set correctly as the SAT will check these details and reject documents with unexpected combinations.
In Mexico, a General Public Invoice (Factura al Público en General) is a type of tax document issued to record sales made to customers who do not request an invoice with a specific Federal Taxpayer Registry (RFC) number. Instead, a generic RFC is used to identify the recipient:
  • XAXX010101000 for domestic transactions
  • XEXX010101000 for foreign transactions
This type of invoice is mandatory for businesses that sell to the general public and do not issue individual invoices for each transaction.To create this type of invoice in Invopop:
  • the customer field is not required,
  • the $tags field is used to identify this as a simplified invoice.
The Global Invoice is used to group a set of invoices into a single CFDI document.Notice:
The credit note (nota de crédito) is used to correct, cancel, or refund a previously issued invoice.Notice:
  • the type field has been set to credit-note,
  • the preceding field has been used to identify the invoice that is being corrected.
This is a payment receipt (comprobante de pago, or REP) issued when collecting a payment against one or more invoices that were issued with the PPD (Pago en Parcialidades o Diferido) payment method. It is modelled as a GOBL bill.Payment document rather than an invoice, and must be processed through the SAT issue payment workflow.Notice:
  • the $schema is set to bill/payment and the type to receipt,
  • each lines[].document references an invoice being settled by this payment, identified by its series, code, and the SAT UUID (sat-uuid) stamp of the original CFDI,
  • the amounts on each line follow a strict convention:
    • payable is always the total amount payable on the referenced invoice across all installments,
    • advances is the total already paid in previous installments (omit it, or set 0, on the first installment),
    • amount is the portion of the invoice settled by this payment,
    • installment is the ordinal of this payment against the invoice,
    • due is calculated automatically from the other fields; you don’t need to set it yourself,
  • the third line (invoice LMC 0023) illustrates a later installment that doesn’t fully settle the invoice: payable 1000.00, advances 500.00 already paid, amount 250.00 paid now, leaving a positive due of 250.00 for a future receipt,
  • lines carry the tax breakdown of the invoice being paid, including retained taxes,
  • the single methods entry describes how the payment was received; gobl build maps the credit-transfer key to the mx-cfdi-payment-means extension 03,
  • other extensions that are set automatically on running gobl build: the document mx-cfdi-doc-type is set to P and the customer’s mx-cfdi-use to CP01,
  • this particular example also carries a preceding block, which implies that this receipt substitutes one previously issued — gobl build fills in the mx-cfdi-rel-type extension 04 (Sustitución de los CFDI previos) (omit the preceding block when the receipt is not a replacement), and,
  • there are no totals in the minimal version; running gobl build calculates the line taxes, the payment total, and all balances.

​
FAQ

Individual CFDIs are not required for sales under MXN $100, but those sales must still be included in the global CFDI. Often issuing all invoices will simplify your operation.
Yes. We obtain the supplier’s CSD (digital seal) and credentials to issue invoices in that company’s name. Read more in our white label use case.
Yes. The mx-cfdi-v4 addon supports both PUE and PPD on the original invoice, and Invopop also issues the subsequent payment receipts (REPs / Pago / comprobante de pago) that must be emitted as payments are collected. Model each receipt as a GOBL bill.Payment referencing the PPD invoices being settled and run it through the SAT issue payment workflow. See the payment receipt example in the issuing guide.
Yes, if the original was issued as PUE and payment is not received by the last day of the issuance month, rule 2.7.1.32 RMF requires cancelling the original and re-issuing as PPD with FormaPago = 99, then issuing REPs as payments come in. This is calendar-driven, not payment-event-driven, and it surprises most non-Mexican implementations. The conservative approach is to issue PPD whenever there is any uncertainty about same-month payment.
REPs must be issued by the fifth calendar day of the month following payment receipt (rule 2.7.1.35 RMF). Missing the deadline does not invalidate the underlying invoice, but it prevents the customer from deducting the expense in the correct period and exposes the issuer to fines. This is a recurring source of friction and the reason customers will sometimes refuse to accept cancellations from a supplier with poor REP discipline.
Install the SAT Mexico app (uses SW Sapien as PAC) plus the SW Sapien app for credentials. Onboard each issuing supplier with their CSD certificate and mx-cfdi-issue-place. Run invoices through the Issue CFDI workflow.
The library that transforms GOBL into CFDI documents is publicly available as an open-source project and can be found at github.com/invopop/gobl.cfdi.For further details on how GOBL prepares data for conversion, see the Mexico Tax Regime.
The most common cause is a mismatch between the receiver’s postal code in the CFDI and the postal code SAT has on file for that RFC. Resolution: ask the customer for their CIF (Constancia de Situación Fiscal) and use the postal code printed there, exactly. Secondary causes:
  • The postal code is real but not yet in c_CodigoPostal. Use the closest catalog code from the place of issuance.
  • The receiver is XAXX010101000 or XEXX010101000 and DomicilioFiscalReceptor differs from LugarExpedicion. They must be equal for generic RFCs.
  • The branch issuing the document is configured with the matriz’s postal code instead of its own.
In Mexico, a reduced VAT rate of 8% applies to transactions in border zones (northern and southern border regions). To successfully issue invoices with this rate, both of the following conditions must be met:
  1. The supplier’s RFC must be enabled by the SAT to invoice with the reduced rate in border zones.
  2. Both the mx-cfdi-issue-place field and the customer’s postal code (when included) must correspond to border zones.
If either condition is not met, the SAT will reject the invoice with an error.
CFDI40999 is a generic “unclassified error” returned by the SAT when no other, more specific error code applies. This error can have multiple causes.A common scenario is invoicing in border zones with the reduced 8% VAT rate. If you receive this error in that context, verify:
  1. RFC registration: The supplier’s RFC must be registered in the taxpayers registry for the appropriate border region tax incentive. Without this registration, the SAT will reject all invoices with the reduced rate. See SAT’s registration requirements and procedures for more information.
  2. Issue place postal code: The mx-cfdi-issue-place field must contain a postal code from a municipality within a border zone.
  3. Tax rate: Ensure you’re applying the correct percentage (typically 8%) for the border zone.
If the error persists after verifying these points, or you’re getting this error for other reasons, please reach out to our support team.
This error appears when you try to issue an invoice for a supplier (identified by its RFC) that has not been registered in your workspace. Before you can issue on a supplier’s behalf, its CSD certificate must be uploaded and validated through the registration flow.To fix it, make sure the supplier is correctly registered by following the Register a supplier steps in the supplier registration guide.In Sandbox you may also hit this error for suppliers that were registered in the past. This is due to a change in how supplier registration is now enforced before sending invoices. To resolve it, open the supplier’s Silo Entry in the Console and run the registration process again from the start, completing every step.
The UsoCFDI must be allowed for the receiver’s RegimenFiscal. The catalog defines the valid combinations; not every code works for every régimen. For example, D01–D10 (personal deductions) are only valid for individuals, never for legal entities. RESICO contributors (régimen 626) have a restricted set. When in doubt, default to S01 (Sin efectos fiscales) — it is always valid but produces a non-deductible invoice for the receiver. Always ask the customer which UsoCFDI they need before issuing.
By default, Invopop uses Mexico City’s time zone (UTC-6) when automatically setting the issue_date and issue_time fields. However, the SAT validates these fields based on the time zone of the postal code specified in mx-cfdi-issue-place.If the issuing location is in a different time zone, the SAT may reject the invoice with an error indicating the timestamp is in the future, as it only allows up to 5 minutes ahead of the local time.To avoid this, explicitly set issue_date and issue_time in your GOBL invoice using the local time zone of the issuing location when operating outside Mexico City’s time zone.
For non-MXN invoices, TipoCambio must be present and use the FIX rate published by Banxico in the DOF the day prior to the operation (Article 20 CFF, Article 56 Ley Aduanera). Common errors:
  • Using the day-of rate instead of the prior day’s.
  • Quoting the inverse (USD per MXN instead of MXN per USD).
  • Setting TipoCambio on an MXN invoice (it must be 1 or absent).
  • Rounding inconsistently between line totals and document totals — Anexo 20 has specific rounding rules.
See the Mexico tax regime in GOBL for tax categories, RFC structure, and CFDI extensions. The mx-cfdi-v4 addon documents required fields including UsoCFDI, RegimenFiscal, and place-of-issue.
More available in our Mexico FAQ section

Participate in our community

Ask and answer questions about invoicing in Mexico →