AWRA OpsHub Search

Mexico · Latin America

In Mexico the invoice goes to the government first. Ours goes to the printer.

Article 29 of the Código Fiscal de la Federación requires a receipt to be sent to SAT before it is issued, so that SAT can validate it, assign its folio and apply its own digital seal. Only then may it reach your customer. The statute is explicit about the printed copy: it *"merely presumes the existence"* of the receipt. That is the sharpest scope boundary on this whole site — we produce documents, not cleared documents — and rather than say "no e-invoicing" and leave it there, below is the field-by-field list of what the law requires, what our schema holds, and the one requirement we cannot express at all.

The subject
Not a rate. The order of events. Article 29 of the Código Fiscal de la Federación puts the tax authority between you and your customer, before the invoice is issued rather than after.
What we do not do
We do not clear invoices, at all. No connection to SAT, no seal certificate, no folio. There is no partial version of this and no configuration that changes it.
The checkable part
Nine requirements in article 29-A against our schema, measured rather than remembered — five partly held, two entirely absent, and the absences are named with the reason.
The rate, for completeness
16%, and the Ley del IVA sets only one. Businesses in the border zones may bear less through a separate fiscal stimulus — a benefit applied for and time-limited, not a rate the country has.

Código Fiscal de la Federación, articles 29 and 29-A

Three parties, and the order is fixed by statute

This is not a filing deadline or a monthly return. It is the act of issuing an invoice, and the state is in the middle of it. Article 29 sets out the sequence and article 29 fraction IV is the part most systems are not built for — the receipt goes to SAT *antes de su expedición*, before it is issued.

Step 1

You

Build the receipt as a digital document and sign it with your own digital seal certificate, which you obtain from SAT and which is regulated like an advanced electronic signature.

We build a document and store it. We hold no seal certificate and sign nothing.

Step 2

SAT

Validates the article 29-A requirements and any required complements, assigns the folio, and incorporates its own digital seal. Until this happens the document has no fiscal existence.

Nothing in our product talks to SAT, and nothing assigns a folio that anybody but us recognises.

Step 3

Your customer

Receives the sealed electronic file, and a printed copy only if they ask. They can check the folio against SAT themselves.

Receives our PDF, which under article 29 fraction V is the thing that merely presumes a receipt exists.

Read the third row against the first two. A business using us in Mexico would be handing customers the printed representation of a receipt that was never created. That is not a gap in a feature list — the document does not exist, and the amounts on it cannot be deducted or credited by the person who received it.

Our own limitation, stated field by field

What article 29-A requires, and what we hold

This is the checkable part. Article 29-A lists what a receipt must contain; the middle column is our schema, measured rather than remembered. Most of it is closer than you would expect from a product with no clearance at all — which makes the one empty row worth finding before you shortlist us rather than after.

Issuer tax registration, name and fiscal regime

Organization name and tax registration, yes. Fiscal regime, no field.

Partly

SAT's folio, SAT's digital seal and the issuer's digital seal

None of the three. This is the clearance itself.

Nothing

Place and date of issue

Date, yes. Place of issue is not held per document.

Partly

Recipient tax registration and name

A tax number field exists on the customer record and the name is held. Nothing validates the number's form.

Partly

Postal code of the recipient's fiscal domicile

Customer addresses carry a postal code. Nothing marks which address is the fiscal one.

Partly

The code for the use the recipient will make of the receipt

No field, and it is a per-document value rather than a customer attribute.

Nothing

Quantity supplied

Held on every line.

Held

Unit of measure

Nothing. There is no unit of measure anywhere in our schema.

Nothing

Class of goods or description of the service, using SAT's catalogues

A free-text category and a description. No classification key.

Nothing

The row we did not expect

We went looking for anything in our data model that records a unit. Everything we found records a price per unit and nothing records the unit itself. We can tell you what one of a thing costs and we cannot tell you what one of a thing is. For most of the markets on this site that has never mattered, because a line reading "12 × Blue paint" is a sentence a human reads. Article 29-A fraction V does not want a sentence — it wants a quantity, a unit of measure and a class of goods, the last two drawn from catalogues SAT publishes. Two of those three are not in our data model at all.

That is a schema change rather than a setting, and it is the honest first line of any Mexican quotation we would give: a unit of measure on the item and on the line, a classification key beside it, and the recipient fields above — before a single call to SAT is written.

And you cannot simply void one

A receipt may be cancelled only in the year it was issued, and only if the person it was issued to accepts the cancellation. Where the receipt covered income, the reason has to be justified and documented, and the tax authority may come and look at that justification. Separately, returns, discounts and rebates are not adjustments you make quietly — each one requires its own receipt.

Cancelling an invoice in our product sets a status. There is no counterparty step, nothing asks the customer, no year boundary is enforced, and no reason is required. And our credit note is a single amount with no lines and no tax on it at all — so the document Mexico treats as a cleared fiscal receipt in its own right is, with us, the thinnest record on the system.

What this costs

Four things to establish before a demonstration, not during one

None of these show up as an error. A document that has never been cleared formats correctly, totals correctly and prints beautifully — and the person who carries the consequence is usually your customer rather than you.

A document that is not a document

The first thing to establish about any system you are shown is whether the invoice it produces has been to SAT. If it has not, what you are looking at is a printed representation of a receipt that does not exist — and the person who suffers for that is your customer, because amounts on a receipt that does not meet the requirements cannot be deducted or credited.

Fields that are not on your customer record

A tax registration, a fiscal regime, the postal code of a fiscal domicile and a code for what the customer will use the receipt for. Four attributes that most systems built elsewhere have no column for, and which are not optional here. Ask to see the customer form, not the invoice.

Catalogues, not free text

The class of goods and the unit of measure come from catalogues the authority publishes, so a product master full of well-written descriptions is not the same as a product master that can be invoiced from. This is the requirement most often discovered during an implementation rather than before one.

A cancellation your customer has to agree to

Voiding a document is a two-party act here and it has a deadline attached to the calendar year. A system whose cancel button is a status change is not modelling the thing the law describes, and the gap shows up the first time a customer refuses.

Operations in Mexico

A clearance regime is a finance department problem. Most of the year is a warehouse problem.

The section above is a genuine boundary and it deserved the top of the page. It is still one department's problem. What an operator here actually spends the year on is stock moving between distribution centres, batches and expiry dates that have to be traceable backwards, purchases whose landed cost arrives weeks after the goods, and an asset register that has to answer to an audit. All four are shipped, and none of them cares whether an invoice has been sealed.

Inventory

Stock by location, with transfers that are confirmed at both ends

Every warehouse, store and holding location keeps its own position. A transfer is a movement with a state rather than a subtraction here and an addition there, so goods between two centres are visible while they are between them, and a receipt that does not match what was sent is a discrepancy somebody can see rather than a number that quietly settles.

Inventory

Batch and expiry tracing that runs backwards

Batch and expiry tracking with a full movement trace: which batch a quantity came from, every place it went, and what is left where. Allocation orders by expiry automatically. The question a recall asks is the backwards one — where did this batch end up — and that is the direction the trace is built to answer.

Procurement

Landed cost allocated across the goods it belongs to

Freight, duty, handling and the charges that arrive after the shipment are entered against the purchase order and spread across the batches received from it, by value or by quantity. Where an import charge is not reclaimable, that is the only route by which it reaches the cost of the goods rather than a general expense account — and margins that never see it are overstated for as long as the stock is held.

Assets

An asset register built to be examined

Custodian, location, condition, movement history, verification dates and documents attached per asset. The value of it is that it is assembled continuously rather than reconstructed when somebody asks, which is the only version of an asset register that survives being asked about.

Scope in Mexico

What runs today, and what is not a configuration away

The right-hand column is unusually short on qualifiers for this corpus, and deliberately so. Clearance is not a feature we have partly built or could enable for a customer who asked nicely — it is absent, and the two schema gaps beneath it are the ones that would have to be closed before it could even be started.

Scope in Mexico, and the boundary is not a soft one

Running in the product today

  • A rate stored per invoice line, so any document can be raised at any rate and none of them re-resolve later.
  • Item-level tax treatment, so the item can carry the taxability decision rather than the person raising the document.
  • Batch, expiry and backwards movement tracing, with allocation ordered by expiry.
  • Landed cost allocated across received batches, by value or by quantity.
  • Stock by location with transfers confirmed on receipt, and goods in transit modelled as a state.
  • A tax registration field and a postal code on the customer record, which is two of the four recipient attributes the law asks for.

Not built — and the first three are the reason to read this page

  • We do not clear invoices with SAT, at all. No connection, no digital seal certificate, no folio, no certification provider. This is the whole disclosure and there is no partial version of it: a document our system produces has not been to the authority, and under article 29 that means it has not been issued.
  • There is no unit of measure anywhere in our schema. Not on the item, not on the invoice line, nowhere. Article 29-A requires one on every line. We went looking, and everything our data model holds about a unit is a price per unit — never the unit itself.
  • There is no product or service classification key. Our item carries a free-text category, and the law wants a class of goods drawn from the authority's own catalogue.
  • No fiscal-regime field and no use-of-receipt field. The first is a customer attribute we do not have; the second is a per-document value we have nowhere to put.
  • Cancellation is a status we set. There is no recipient acceptance, no calendar-year boundary and no required reason.
  • Our credit note carries no lines and no tax — a single amount — where Mexico treats the equivalent document as a cleared fiscal receipt in its own right.
  • No Mexican payroll engine. No income tax tables, no social security calculation, no filing. We attribute labour cost to projects and departments and stop there.

How this starts

Four moves, and none of them is a demonstration

01

Ask whether the invoice has been to SAT, before anything else

Not whether the vendor "supports CFDI" — ask to watch a document be created and then ask where the folio and the seal came from. If the answer involves a spreadsheet, a separate portal or a third product, that is your real invoicing system and the one you are being shown is a record of it.

02

Open the customer form and the item form, not the invoice

The invoice is where every system looks best. The requirements that break implementations are attributes of the customer and of the item: a fiscal regime, a fiscal domicile, a classification key and a unit of measure. Count how many of the four have a field.

03

Ask what a cancellation does to the counterparty

A cancel button that changes a status is not the thing the law describes. Ask how the customer is asked, what happens when they decline, and what stops a cancellation being attempted after the year has closed.

04

Decide what you want us for, and say so early

We are a defensible choice in Mexico as the operational layer beside a clearance product — stock, batches, landed cost, assets, approvals — and a bad choice as the thing that issues your invoices. That is a straightforward conversation to have in week one and an expensive one to have in month six.

Questions we are asked here

Straight answers, starting with the one that decides it

Does AWRA OpsHub issue CFDIs?

No. There is no connection to SAT, no digital seal certificate, no folio and no certification provider anywhere in the product. Under article 29 of the Código Fiscal de la Federación a receipt must be sent to SAT before it is issued, and SAT assigns the folio and applies its seal — none of which we do. What we produce is the printed representation, which the statute itself describes as merely presuming that a receipt exists. If you need invoices issued in Mexico, you need a product that clears them, and we would say so in the first meeting rather than the fourth. It is not a permanent limit: the field work in the last answer is commissionable, and the clearance itself is a build against a published specification, with our Kenyan tax-filing integration as the evidence that we build this way. What it is not, in any version, is a setting somebody can switch on for you.

What is the IVA rate, and what about the border zones?

The Ley del Impuesto al Valor Agregado sets one rate, 16%, in article 1, and that is the figure we ship as your default. Businesses in the northern and southern border zones may bear less, but that comes from a separate fiscal stimulus granted by decree rather than from a different rate in the Act — it has to be applied for, it carries conditions, and it expires unless extended. We deliberately do not print a border figure here, because we have read the Act and not the decree, and a benefit you hold is not the same thing as a rate your country has.

Could we use you alongside a CFDI product?

That is the arrangement we would actually recommend, and it is the reason this page exists rather than a polite refusal. The clearance product owns issuing and cancelling; we own what happens around it — stock across locations, batch and expiry traceability, landed cost reaching the cost of goods, purchase approvals, the asset register and the ledger. The join is your customer and item masters, and the fields listed above are what would have to be kept consistent between the two systems.

You say there is no unit of measure. Is that really true?

Yes, and we checked it rather than assumed it: every column in our database whose name contains "unit" is either a unit cost or a unit price. A line can say twelve, and it cannot say twelve what. For most markets that has never surfaced, because a description does the work for a human reader. Article 29-A fraction V asks for a quantity, a unit of measure and a class of goods, and expects the last two to come from the authority's catalogues — so in Mexico it stops being a presentation detail and becomes a data-model change.

What would it take for you to be usable here for invoicing?

In order: a unit of measure on the item and on the line, a classification key beside it, a fiscal regime and a fiscal domicile on the customer, and a per-document use code. Then the clearance itself — a seal certificate, the pre-issue submission, the folio and seal coming back onto the document, and a cancellation flow with a counterparty step. The first group is a schema change and we would quote it as one; the second is an integration against a published specification. We would rather set that out as a scope than let it be discovered one field at a time.

Do you file returns or produce anything for SAT?

No. We produce no Mexican return in any format the authority accepts, and we do not transmit anything. Reporting from the ledger is ours; the filing is yours or your accountant's. A Mexican return is buildable against a published specification and it is commissionable, but we would put it behind the field work above rather than in front of it: a return assembled from documents that were never cleared would be a tidy summary of the wrong thing. Separately and practically, filing here is conducted in Spanish and our interface is English — worth naming once, because it matters to a finance team even though it is not a compliance question.

Bring the invoice you have to produce

Show us one real cleared receipt with its fields filled in, and we will mark up which of them our schema holds today, which are a configuration away, and which are a build. It is a twenty-minute conversation and it will tell you whether we belong on your list at all.