Addendas and complements: what the PAC actually validates

There is a phone call we get every couple of months. On the other end is someone from accounts receivable, XML open on the screen, saying the exact same sentence:

«The invoice is stamped. Here is the UUID. So why am I not getting paid?»

And it really is stamped. The seal is valid, the SAT acknowledgement exists, the document shows up in the portal. The retailer rejected it anyway, the purchase order is still open, and payment slipped another full cycle.

The explanation almost never involves the SAT: the PAC does not check everything in your invoice. It checks one part. The other part is checked by your customer, and you find out about that weeks later.

A CFDI is two documents in the same file

Underneath the XML there are two zones with completely different rules. Simplifying the structure:

<cfdi:Comprobante>
  <cfdi:Emisor/>
  <cfdi:Receptor/>
  <cfdi:Conceptos/>
  <cfdi:Impuestos/>

  <cfdi:Complemento>
    <!-- defined by the SAT · inside the seal · the PAC validates it -->
  </cfdi:Complemento>

  <cfdi:Addenda>
    <!-- defined by your customer · outside the seal · nobody validates it -->
  </cfdi:Addenda>
</cfdi:Comprobante>

They sit two lines apart and have nothing in common. In fact, almost every invoicing problem with large Mexican retailers comes down to that difference.

The complement: the SAT asks for it, the PAC checks it

A complement is a tax extension. The SAT defines it, publishes its schema — the XSD — and states which sector or operation it applies to. This is where payment receipts, foreign trade, carta porte, payroll, tax legends, local taxes, the INE complement and the one for donatarias all live.

Three things define it:

1. It sits inside the complement node and is part of the document itself.
2. It goes into the cadena original, so the digital seal covers it.
3. The PAC validates it before stamping. Fail the schema and nothing gets stamped.

And there is good news hidden in there: when a complement is wrong, there is no invoice. The document does not exist. It is a loud, immediate, impossible-to-ignore error. It stops you the same day, which is exactly what you want an error to do.

The addenda: your customer asks for it, and nobody checks it

An addenda is a commercial extension. The SAT does not define it — the buyer does. Chedraui asks for its own thing, Liverpool for its own, Walmart for its own, and none of them have any reason to look alike.

The SAT simply reserved the node and stepped aside. What goes inside is an agreement between private parties, and that gives it three properties:

1. The receiver defines it, with its own catalogue and its own schema.
2. It does not go into the cadena original. That is why it can be attached to an already-stamped XML without invalidating the seal: the seal never covered it in the first place.
3. The PAC does not validate it. The SAT does not even read it.

And there is the bad news. If the addenda is wrong, or simply missing, your invoice stamps perfectly. Your ERP says everything is fine. Your accountant says everything is fine. The SAT says everything is fine. And the retailer's receiving portal rejects it without anyone noticing until someone asks about the payment.

A broken complement stops you from invoicing. A broken addenda lets you invoice and stops you from getting paid. The second one hurts more because it takes longer to surface.

Why addendas exist at all

The reason is worth understanding, because it explains why this will never get simpler.

A CFDI is a tax document. It cares about who sells, who buys, what was sold, how much it cost and what taxes it triggers. Nothing else. It is deliberately austere, and it should be: it is the same invoice for a corner tortilla shop and for a car plant.

The retailer cares about things the SAT is entirely indifferent to: your supplier number in their system, the purchase order folio, the GLN of the receiving centre, the delivery number, the product code in their catalogue — which is not your SKU — the shipping note, the counter-receipt.

Without that data their portal cannot reconcile three documents that have to match: the purchase order, the goods receipt and your invoice. If they do not match, it does not pay. This is not bureaucracy for its own sake: it is the only way a company with thousands of suppliers reconciles without doing it by hand.

The SAT was never going to standardise that, because it changes from company to company and from year to year. So it left a free node and washed its hands of the contents. The addenda is, quite literally, the blank space the SAT left behind.

Complemento detallista, which confuses everybody

Here is the exception that breaks the clean explanation, and it is worth knowing because it causes the most arguments.

The complemento detallista genuinely is published by the SAT, with its own schema, in the official list of complements. It grew out of the retail sector standard. But it is not mandatory: the SAT describes it as a facility for that sector, not as a tax requirement.

In practice, many retailers ask for that very same standard inside the addenda, not as a complement. Same format, different node, different validator. That is why some people will swear detallista is a complement and others will swear it is an addenda — both are right about whatever they happened to see.

The practical move is to stop arguing about the name:

Do not look at what it is called. Look at which node the specification you were sent puts it in. That decides who validates it, when you find out if it is wrong, and who you will be calling when it bounces.

"My PAC generates it for me"

Several PACs offer addenda generation as an add-on service. That is true, it exists, and it works. But it helps to know what you are buying: that is a commercial product from the PAC, not tax validation.

The stamp does not vouch for the addenda. If the retailer changes its catalogue and yours goes stale, your invoices will keep stamping just as validly — and keep bouncing just as fast. Responsibility for keeping the content current does not travel with the stamp.

What this changes if your ERP is Odoo

This is where the distinction stops being theory and turns into budget.

An addenda is almost always a data problem: you need to capture the supplier number, the GLN, the order folio and the codes from your customer's catalogue, then write them into the node in the shape that particular retailer demands. All of that lives at the customer level and is solved with fields configured inside Odoo itself. That is why an addenda is reachable on both Odoo Online and Odoo.sh, with nothing installed and no server access. It is the part most vendors present as impossible on SaaS, and it is not.

A complement, on the other hand, is the tax document itself. If the Odoo localization does not generate it — or if the retailer demands a structure the localization never contemplated — no configured field will save you: the XML has to be produced another way. And there, your environment really does decide what options you have.

We wrote up that full decision tree separately, along with the chains we have already solved and what to do in each environment: addendas and invoicing complements.

Before you accept the next purchase order

When a new retailer comes in, ask for their specification and ask one question before any other:

Does this go in the complement or in the addenda?

The answer tells you three things at once: who validates it, when you will find out if it is wrong, and how big the job is. It is the cheapest question in the whole project, and almost nobody asks it in time.