Mexico eInvoicing: A Summary of Key July 2012 Changes

Spend Matters welcomes a guest post from Steve Sprague, Vice President, Marketing & Product Strategy at Invoiceware International.

Compliance is the dominating theme of electronic invoicing for the foreseeable future, especially for corporations operating or looking to expand their business in Mexico. It all started in Brazil -- but over the past two years, Mexico has also adopted a more intricate series of legislation and regulations around electronic invoicing. Mexico's Servicio de Aministracion Tributaria (SAT) from December 2011 provided a new set of requirements that go into effect on July 1, 2012. Below is a summary of the key changes:

  • Shipping Requirement: New requirement that all deliveries within Mexico must have the Comprobante (i.e. the Invoice) as part of the documentation accompanying the truck for delivery. Otherwise the truck and its goods can be impounded with fines demanded before release. This is a significant change for customers that do not have their logistics and invoicing processes linked together today.
  • Account Number: Emisor's are expected to know and report the last 4 digits of the account numbers that their customers use for payment.
  • Fiscal Address: the street and address will no longer be required, but the country, state and postal code still will.
  • Installment Payments: for installment payments, the emisor must send an invoice for each payment, plus an "informational" invoice to document the entire amount.

Outside of these legislative changes, the top question that comes up in virtually every Mexico e-Invoicing meeting I host is: Do I really need to do the inbound validation of invoices? Many companies think that they don't. But this oversight can lead to potential jail time and heavy fines. There are two realities in Mexico CFDI for inbound invoices:

  1. Validation is not required in the current articles around the technical implementation
  2. However, the only way to ensure you pay your taxes correctly and avoid committing fiscal fraud is through validation. In my experience, approximately 15% of all inbound invoices are fiscally invalid in Mexico.

So it is not a technical enforcement that should be driving decisions. Instead, it should be a fiscal decision. In Mexico, you pay taxes to the government based on the net difference (i.e. the tax you charge your customers minus the tax that you pay your suppliers). If you are deducting these tax payments on your fiscal books, then not validating every single inbound invoice is just lighting the fuse of an "audit bomb" and then throwing accelerant onto the flame.

We have seen Mexico move more towards the Brazil NFe model on the outbound invoices in the past year, whereby the approvals are required prior to the truck leaving a warehouse. We expect to see similar mandated legislations in a more formal technical design in coming months for inbound processing. But this is not a plausible excuse to wait on the implementation of inbound validation.

With v.3.2 in Mexico, suppliers must make the XML invoice available to an end buyer. This is traditionally done via e-mail, but many companies are looking at EDI communication as well as upload portals to simplify their process of collection. Once you have this XML, you can validate the signatures, certain values, and post returned validation signatures in your system of record. This will ensure, when/if you are ever audited, that all of the invoices and tax deductions you take are from only valid and government approved invoices. The process is not difficult, but too many companies are putting their fiscal manager and controllers at risk of criminal penalties. This can all be avoided with a short 4-6 week project. Make sure you understand the realities of both the technical requirements as well as the fiscal requirements -- they are not separate issues anymore.

- Steve Sprague, Vice President, Marketing & Product Strategy, Invoiceware International

Discuss this:

Your email address will not be published. Required fields are marked *