Comercio Exterior complement for CFDI exports
May 5, 2026
A $180,000 USD export was held up at customs because the CFDI (Mexico's electronic invoice) came without the Comercio Exterior complement (Comercio Exterior: the CFDI foreign trade complement for exports; complement: complemento, an XML extension the SAT defines for specific operations). The customer wasn't a manufacturer. It was a distributor selling to the United States for the first time. Its system issued correct income CFDIs (type I, the regular sales invoice) for Mexican customers. For the foreign customer, the team swapped the recipient's RFC (Mexico's taxpayer ID, Registro Federal de Contribuyentes) for the generic foreign RFC and assumed that was enough. It wasn't. The goods sat at customs for eight days.
This post exists because that case isn't rare. The Comercio Exterior complement is one of the places where documentation from the SAT (Mexico's tax authority, Servicio de Administración Tributaria) assumes context you only have if you've already invoiced exports. Worse, there's genuine confusion about which CFDI type carries it. Here's the short answer and the long version.
What is the Comercio Exterior complement
The Comercio Exterior complement (complemento de comercio exterior, or CCE), the CFDI export complement, is an XML node you attach to the CFDI when the transaction is a definitive export of goods (pedimento key A1; pedimento: the Mexican customs declaration for imports and exports). It identifies the issuer, the foreign recipient, and each item of goods with its fracción arancelaria (Mexico's 8-digit tariff code: the 6-digit Harmonized System code plus 2 Mexican digits), customs quantity, and value in dollars. The SAT uses it to cross-check the tax data against the customs declaration and confirm that the export matches what was declared.
The current version is 2.0. It has been in force since January 18, 2024, when its SAT catalogs took effect, and it's the only version the SAT accepts. Version 1.1 was valid until January 17, 2024. If your system still builds 1.1, the migration to 2.0 is overdue.
The complement is required only for definitive exports of goods that are sold (pedimento key A1). Temporary exports must not carry it, and returns and services provided abroad don't require it. When there's no sale, or the goods are given away (donations, samples), it's optional. That distinction decides whether your CFDI needs the node.
Income CFDI and transfer CFDI: both can carry it
This is the part that confuses most people. The Comercio Exterior complement isn't tied to a single CFDI type. The SAT accepts it on income, credit note, and transfer CFDIs, and an export uses one of two:
When it applies: There's a sale. The Mexican exporter charges the foreign customer for the goods.
Who issues it: The seller (resident in Mexico).
Recipient: The foreign customer. You use the generic foreign RFC XEXX010101000 and fill the complement's Receptor node with the buyer's address and the tax ID from the buyer's country. The buyer's name goes in the CFDI's own Receptor node.
CFDI total: The sale amount, usually in dollars at the day's exchange rate. The IVA (Mexico's value-added tax, VAT) rate is 0% on exports.
Typical case: A Mexican company sells product to a wholesaler in Texas. It issues an income CFDI with CCE and declares the sale, and the fracción arancelaria in the CCE must match the one on the A1 pedimento the customs broker will file.
This is the most common scenario. If your question is "I sold something abroad, what do I issue?", the answer is almost always an income CFDI with CCE.
The rule worth memorizing: if there's a sale, income. If there's no sale but the goods cross the border, transfer (type T, moves goods without a sale). The Comercio Exterior complement has the same structure in both cases. What changes is the CFDI type you embed it in and the fields of the base CFDI.
When it's mandatory
Not every international transaction requires it. Rule 2.7.1.19 of the Resolución Miscelánea Fiscal (the SAT's annual tax rules) makes it clear, but the SAT published the rule and then a 79-page filling guide to explain it. Here's the condensed version.
| Transaction | Carries CCE? | CFDI type |
|---|---|---|
| Definitive export with a sale (key A1) | Yes | Income |
| Transfer of your own goods abroad | Optional | Transfer |
| Shipment on consignment abroad | Optional | Transfer |
| Samples with no commercial value sent abroad | Optional | Transfer, or income with a discount for the full amount |
Temporary export (Exportacion 03, keys such as BF or BM) | No | Plain transfer |
| Donations to foreign residents | Optional | Transfer, or income with a discount for the full amount |
| Services provided abroad | No | Income without CCE |
| Sales to Mexican residents in free trade zones | No | Regular income |
| Returns of imported goods | No | Plain transfer |
Stamping (the certification by a SAT-authorized provider that makes a CFDI valid) won't always stop you. A CCE on a temporary export (Exportacion 03) is rejected, but a CCE on a transaction that doesn't require it, such as one with Exportacion 04, is accepted. Still, in a later review, an unnecessary CCE can be used to raise discrepancies between what you invoiced and what was declared at customs. If the transaction isn't a definitive export, don't add the complement "to be safe."
The fields the SAT checks
The complement has more than 30 attributes. Most are optional or have short catalogs. These are the ones that cause rejections in production:
The foreign recipient's tax ID
When the recipient's RFC is the generic foreign one, the complement's Receptor node requires NumRegIdTrib, the equivalent of the RFC in the buyer's country. For the United States it's the EIN or SSN, for Canada the Business Number, for the European Union the VAT number. Without it, the complement is rejected.
The error I see most often: sending the number with dashes, spaces, or suffixes. For the United States and Canada, the SAT checks it against the 9-digit pattern in its c_Pais catalog, so a dash gets the CFDI rejected. For countries without a pattern, the SAT accepts any string, but when that CFDI reaches customs and is matched against the pedimento, the formats have to match or a discrepancy is flagged. Clean the value before you send it.
Fracción arancelaria for each item of goods
Each item of goods in the complement must carry its fracción arancelaria, which comes from the TIGIE (Tarifa de la Ley de los Impuestos Generales de Importación y de Exportación, Mexico's import and export tariff schedule). In version 2.0 the FraccionArancelaria attribute takes the 10-digit code from the c_FraccionArancelaria catalog: the 8-digit fracción plus the 2-digit NICO (the 2 digits Mexico adds to a fracción arancelaria to identify goods for statistics, Número de Identificación Comercial). It doesn't have the same structure as the SAT product or service key (ClaveProdServ). The CCE's fracción has to match, digit for digit, the one that will be declared on the pedimento.
If your system keeps its product catalog synced only with the SAT catalogs, you'll be missing this field. Your customs broker determines the fracción, not the SAT, and it's usually information the sales team doesn't have on hand. This is the piece that takes longest in production when you integrate CCE for the first time. More in the Spanish-language fracción arancelaria guide.
Customs quantity and customs unit of measure
These are different from the quantity and unit of the base CFDI. The customs unit comes from the SAT's c_UnidadAduana catalog, and the quantity must be expressed in that unit. If your CFDI sells "1 box with 24 pieces", the complement may need to report "24 pieces" if the fracción arancelaria is measured in pieces, or "12 kilos" if it's measured in kilos.
It's the most frequent question we get from teams integrating CCE. The answer: confirm with your customs broker which unit of measure the fracción requires and map it explicitly. Don't assume the sales unit works.
Value in dollars
The ValorDolares attribute is required on each item of goods, and it's the item's total value in USD, not its unit value. If your CFDI is in MXN, it's the line item amount divided by the complement's TipoCambioUSD. If your CFDI is in USD and its TipoCambio equals the TipoCambioUSD, it's the line item amount.
The catch: the TipoCambioUSD at the root of the complement is required on every CFDI, including those issued in USD. It holds the number of Mexican pesos per US dollar, under Article 20 of the Código Fiscal de la Federación (Mexico's Federal Tax Code), so it's never omitted and never set to "1". Another common trap.
The foreign recipient's address
Street, number, neighborhood or reference, the destination country's postal code, state, and country. The country catalog uses 3-letter ISO codes (USA, CAN, DEU, and so on), not the 2-letter codes many systems store. The base CFDI uses the same catalog in ResidenciaFiscal. If your system mixes both formats, the CFDIs are rejected at validation.
Errors that break issuance in production
After processing exports for customers across different industries, a small set of errors keeps coming back:
How to issue a Mexico export CFDI with the Comercio Exterior complement
The flow is the same as for any CFDI 4.0 with a complement, except that the ComercioExterior node must be built with the exact hierarchy the SAT's XSD defines. Fiscalapi exposes the complement as a typed object in the request (complement.comercioExterior), so you map your export model to the schema and the API handles the XML, the sealing, the stamping, and the response from the PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs).
To integrate it, the Fiscalapi documentation has the reference for the invoices resource with CCE, and the SDKs for .NET, Node.js, Python, PHP, and Java include the typed complement model. The Fiscalapi GitHub has examples of A1 exports with a foreign recipient, the case that covers 90% of integrations.
Questions we get often
If your integration moves goods within Mexico as well as exporting, the Carta Porte guide (Carta Porte: the CFDI complement that documents the transport of goods in Mexico) covers the complement for domestic transport. And if you're migrating catalogs from CFDI 3.3 to 4.0, the CFDI 4.0 guide covers the changes that also affect CFDIs with CCE.