Mexico operations
The Mexican entity is where U.S. ERP projects go wrong.
Not because Mexico is difficult, but because it is specific. The tax authority has requirements no U.S. system was designed around, and finding that out after go-live is what makes it expensive.
What usually goes wrong
None of these are hypothetical. They are what we get called in to fix, in roughly this order.
Invoicing the SAT will not accept
Mexican invoices are not documents, they are electronic records validated in real time by the tax authority. A system that cannot issue CFDI 4.0 correctly cannot legally invoice a Mexican customer — and you find this out in your first week of trading, not before.
A chart of accounts nobody can consolidate
The Mexican entity gets set up locally, by a local accountant, on a local structure, with no mapping to the parent. Every close becomes a translation exercise done by hand, and the errors compound quietly.
Compliance discovered late
Electronic accounting filings, payment complements and payroll stamping each have their own format and their own deadline. Bolting them on after go-live costs several times what building them in would have.
Nobody on the ground
A U.S. consultancy manages the Mexican rollout from a distance, through a local bookkeeper it has never met. When something breaks, the response time is measured in days and languages.
What Mexican compliance actually requires
Plain descriptions of the four obligations that catch U.S. companies out. If your current consultant cannot explain these, that is the answer to your question about them.
CFDI 4.0
Every invoice is stamped by an authorized provider and validated by the SAT before it is valid. The data requirements are strict — the customer's tax ID, legal name and postal code have to match the tax authority's own records exactly, or the stamp is rejected.
Complemento de pago
When a customer pays an invoice, a second electronic document has to be issued against it. Companies that invoice on credit terms generate these continuously, and missing them creates a discrepancy the tax authority can see from its side.
Contabilidad electrónica
The chart of accounts and the trial balance are filed with the tax authority in a prescribed XML format, on a schedule. Each account has to map to the SAT's own grouping code, which is a design decision at setup rather than a formatting step later.
Payroll stamping
If the entity employs people in Mexico, each payslip is itself a stamped electronic document. Payroll and accounting have to agree, because the tax authority sees both.
How we set it up
The decision is not really "which ERP". It is which system carries the Mexican tax obligations, and how the numbers get back to you.
Sage 300 in the U.S., unchanged
Your existing setup keeps running. We do not remodel the U.S. system to accommodate the Mexican one — that trade has never paid off for anyone.
The Mexican entity on the right system
Sage 300 where the entity is small and the CFDI volume is low. Odoo with the Mexican localization where it is not, because there the compliance is native rather than bolted on, and the licensing does not punish you for growing.
One chart of accounts, mapped from day one
The Mexican structure satisfies local requirements and maps to yours. The mapping is built at setup, not reverse-engineered at year end by whoever is available.
Consolidation on a basis your auditors accept
Monthly, in your reporting currency, with the intercompany eliminations already done. The Mexican numbers arrive as part of the close, not three weeks after it.
Opening in Mexico, or already there and struggling?
Tell us where the entity stands — planned, just registered, or trading and painful. We will tell you what the setup should look like and roughly what it costs, before you commit to anything.