What Does the SAT Require for Electronic Invoicing in Mexico?

Monday, seven in the morning. Four trucks sit loaded at the dock, and the largest customer in your portfolio only accepts goods if the invoice arrives before the truck. The first invoice of the day comes back with an error: your company's digital seal certificate, the CSD (certificado de sello digital) that seals every invoice you issue, expired over the weekend and nobody had that date on the calendar. To request a new one you need the company's e.firma, the advanced electronic signature issued by the SAT, Mexico's tax authority, and the file with its password was kept by the accounting firm you stopped working with two months ago. The trucks stay put, the customer reschedules receiving for Thursday, and your billing team spends the morning looking for a USB drive.

To invoice you need an active RFC, a valid e.firma, a digital seal certificate, an authorized certification provider (PAC) and exact tax data on every invoice. Your ERP should monitor all of these requirements before stamping fails.

What the SAT requires before you issue a single invoice

Electronic invoicing in Mexico rests on a chain of prerequisites that almost nobody reviews until one of them fails. Every invoice is a CFDI (Comprobante Fiscal Digital por Internet), the digital tax receipt the SAT recognizes, and at Oasys we group what it takes to issue one into three keys: a tax identity in good standing, two different certificates and an authorized third party that validates each invoice. Some details of these requirements change with the reforms and rules the authority publishes, so we recommend confirming the current conditions for your case with your accountant.

Active RFC and a locatable tax address

The starting point is registration in the Registro Federal de Contribuyentes (RFC), Mexico's federal taxpayer registry, with active status, a tax address the authority can locate, and a tax regime and economic activities that match what your company sells. When any of these details does not match your real operation, the problem shows up late: when you request certificates or in a notice from the authority. Periodically reviewing your own company's tax status certificate (constancia de situación fiscal) is a cheap habit that prevents expensive surprises.

e.firma and digital seal certificate: two keys that get confused

The e.firma identifies your company before the SAT and is used for filings, tax returns and, among other things, to request digital seal certificates. The digital seal certificate (CSD) is the one that seals every invoice you issue. They are separate files, with separate passwords and separate expiration dates, and the e.firma cannot be used to seal invoices. A company can hold several CSDs, for example one per branch or per issuing point, and each one expires on its own.

The operational implication is custody. If the e.firma expires, renewing the CSD becomes a longer process, and if the CSD expires, invoicing stops that same day. Both certificates, their passwords and their expiration dates should be under your company's formal safekeeping, with a designated owner and a backup that depends on neither a single person nor an outside firm.

The certification provider: who gives your invoice tax validity

An invoice sealed by your company needs one more step to have tax validity: it has to go through a Proveedor Autorizado de Certificación, the PAC, a certification provider authorized by the SAT that validates its structure, assigns the fiscal folio number and seals it on behalf of the authority. That step is called stamping, and without it the file has no validity before the SAT or before your customer.

A company that issues dozens or hundreds of invoices a day needs a PAC connected to its system, with the capacity to respond during month-end peaks and with enough stamps contracted for its volume. It also pays to know what your system does if the PAC does not respond and who receives the alert.

Why a misclassified catalog holds up invoices with the right customer

Once the issuer side is in order, every invoice has to describe the transaction using the catalogs the SAT publishes. Many of the invoices customers send back originate in the product master file, long before anyone presses the invoice button.

Product or service code and unit code

Every line item on the invoice carries a product or service code and a unit of measure code taken from the official catalogs, plus quantity, description, unit price and amount. When your company's items are set up without those codes, someone picks them at the moment of invoicing, and the same item ends up invoiced with different codes depending on who entered it. For your accounting team, that inconsistency is hard to explain in a review; for your customer, it can be a reason to request a replacement invoice.

Taxes, form of payment and payment method

The invoice also declares the transferred and withheld taxes on each line item, whether the item is a taxable object, the form of payment, the currency and the payment method. The payment method distinguishes between payment in a single installment, PUE (pago en una exhibición), and payment in installments or deferred, PPD (pago en parcialidades o diferido). In a credit sale, the tax cycle stays open after the invoice: every collection requires issuing the payment receipt complement, which links the money received to the original invoice.

The typical error happens when sales negotiates credit and billing issues the invoice as a cash payment, or the other way around. The invoice is stamped without a problem and the error surfaces weeks later, when accounts receivable tries to apply the payment. That is why the payment terms should be inherited from the customer file and the order, instead of depending on the memory of whoever does the invoicing.

Recipient data: the part CFDI 4.0 made strict

On the customer side, the invoice must carry their RFC, their name or corporate name, the postal code of their tax address, their tax regime and the CFDI use code, all matching what the SAT has on record. In our article on CFDI 4.0 we explain how that validation broke invoicing processes that had worked for years; here a single rule is enough: every customer's tax status certificate should be in their file before they are enabled for invoicing.

The requirements that remain in force after stamping

Stamping the invoice closes only the first part of the obligation. What happens to the invoice afterward is also part of compliance, and that is where mid-sized companies pile up pending items without noticing.

Delivering the XML and keeping the file

The XML file is the invoice; the PDF is only its printed representation. Your company must deliver the XML to your customer, keep the ones it issues and the ones it receives as part of its accounting records for the period the law requires, and be able to retrieve them when the authority or a customer asks for them. An XML stored in one person's email is a document nobody can find on the day it is needed.

Cancellations with a reason and recipient acceptance

Canceling an invoice requires declaring a reason from the SAT catalog and, when it is an invoice with errors that is being replaced, linking it to the new one. Depending on the amount and other criteria the authority adjusts over time, the cancellation may also require your customer to accept it, and there is a deadline for doing it. Because these rules change, confirm the current conditions with your accountant before defining your internal cancellation policy.

Global invoice for sales to the general public

If you sell to consumers who do not ask for an invoice, as happens at counters, stores or restaurant chains, those sales are covered by a global invoice issued at the frequency the authority allows. Your system must exclude from the global invoice the receipts that were already invoiced individually, a control that fails easily in spreadsheets.

The requirement nobody watches until it stops the operation

The requirements that cause the most stoppages are the ones with an expiration date or that depend on third parties: the validity of the CSD, the validity of the e.firma, the stamp balance with the PAC and your own company's tax status. Any one of them can halt all invoicing overnight.

Expiration dates without an owner

In many of the companies that come to us, nobody is formally assigned to watch those dates. The outside accountant assumes IT handles it, IT assumes finance handles it, and finance finds out when the first stamping fails. The fix is simple: an expiration calendar with an owner and a backup, reviewed every month, and a written procedure to renew each certificate without depending on a single person.

How an ERP turns tax requirements into routine controls

Most of these requirements are met or missed inside the system where customers, products and orders are entered. When invoicing lives in a separate tool, every requirement depends on manual entry; when it lives inside the ERP, it becomes an automatic validation.

SAT catalogs inside the product and customer master files

The first control is master data. Every item is set up with its product or service code, its unit code and its tax treatment, and every customer with their regime, their tax postal code, their usual CFDI use code and their payment terms. From there, the invoice inherits that data from the order and nobody has to choose it again at the moment of invoicing.

Validation before sending to the PAC

The second control happens before stamping: the system checks that the customer file is complete, that the codes exist in the current catalogs and that the payment method matches the agreed terms. Errors get corrected at the desk of the person doing the invoicing, with time to spare, instead of showing up in the PAC's response with the truck waiting at the dock.

Invoice, warehouse and accounting in the same flow

At Oasys we integrate CFDI 4.0 electronic invoicing into the same system that runs sales, warehouse, transportation and accounting, with connections to authorized certification providers. The picking the warehouse confirms feeds the invoice with the order data, every movement generates its accounting entry, and the payment complement stays linked to its original invoice when accounts receivable applies the collection. We operate on our own servers in a data center, so the system responds the same way on closing days.

Frequently asked questions

Can I use my company's e.firma to seal invoices?

Invoices are sealed with the digital seal certificate, a separate certificate you request from the SAT using your e.firma, so the e.firma itself cannot do that job. That is why it pays to keep both valid: without a valid e.firma, renewing the CSD becomes a longer process and invoicing can stay stopped in the meantime.

Do I need a PAC if the SAT offers a free invoicing tool?

The tool on the SAT portal works for low volumes and manual entry. If your company invoices every day from orders, delivery notes or shipments, you need a PAC connected to your system, so the invoice is generated with the operation's data and recorded in your accounting without re-entry.

Does each branch need its own digital seal certificate?

You can operate with a single CSD or request one per branch or issuing point. Several certificates let you spread issuance across branches, at the cost of monitoring more expiration dates. Your accountant can help you define the setup that best fits your company's structure.

If your company's invoicing depends on a certificate whose date nobody watches or on codes chosen at the moment of invoicing, the next stoppage already has a date. At Oasys we integrate CFDI 4.0 invoicing with sales, warehouse, transportation and accounting in a single system, on our own servers, so every requirement is validated before stamping. Find out how at https://www.oasys.com.mx/en