With the announcment on May 31, 2013 of the updates to einvoicing in Mexico, there is a huge amount of interest - yet one potential failing of many companies.
CFD is sunset, there are no "grandfather" clauses in the updates. Many organizations have been lulled into a peaceful sleep with the older knowledge that the government would still accept CFD. This is because in the past (and by past I mean before May 31, 2013) you could still send CFD XML if you had been doing CFD prior to Jan 1, 2010. There have been a number of CFDI mandates since then, and the CFD "grandfather" clause had always applied. UNTIL NOW -- in the resolution posted on the Mexico SAT website CFD is no longer viable as of January 1, 2014:
The official documentation of the legislative changes was published: El 31 de mayo de 2013 se publica en el DOF la 2ª Resolución de Modificaciones a la Resolución Miscelánea Fiscal para 2013 (2ª RM para la RMF 2013). Link to Mexico SAT Documentation
With CFD eInvoicing no longer allowed -- are are the basics you need to understand about CFDI in Mexico:Establishing a Legal Entity
Obtain a Registro Federal del Contribuyente RFC (Mexican Tax ID)
With the RFC apply for FIEL (Firma Electronica Avanzada). It is based on PKI Public Key Infrastructure to identify and verify the information about tax payer before the SAT (Mexican Tax Authorities).
With the FIEL apply for CSD (Certificado Sello Digital) to be used with CFDI process flows
Have a solution provider capable of mapping your proprietary invoices into XML v3.2 defined by Anexo 20 of the Mexican tax code Miscelania Fiscal. This is by far the most underestimated issue with CFDI invoices as no customer accounting system is configured the same. Additionally, your customer specific requests can also have a major affect and create an integration nightmare to force your data into the government standard (not once but across all the different variations you have in your business and all the different variations requested by your customers
Apply a digital signature known as a sello with the CSD.
Validates the XML syntax obtain the “Timbre Fiscal” or government seal
You must store the “Timbre Fiscal” in your back-end accounting system
You must print out the invoice, which now includes the “Timbre Fiscal” and the strictest following of the law states you should place a copy on the truck at the time of shipping – similar to the Brazil Nota Fiscal model.
By law, you must make the signed XML available to your end customers
Most companies will send the signed XML invoice and the PDF rendering to the customer via email, but other channels exist such as B2B communications or uploading to a customer portal
These invoices must be stored for a minimum of 5 years.
If you have to change the invoice, you must first cancel the original invoice with the government and generate a new one; otherwise, you will still be on the hook for the older invoice tax implications
Note: Large customers can make the process more complex by requesting “Addenda” information. An Addenda is a specific space within the government XML that you can put specific information. The government does not care about this information, but for example a Wal-Mart might want the supplier to put the PO # in the Addenda, so they can expedite their payables process. Customer requirements can make the entire process much more complex as you can get these Addenda requests and/or a customer may request a lot of additional information on the PDF printout that is specific to them.
As a buyer, when you receive the XML invoice. The laws state that you need to validate that the XML is authentic and registered with the SAT and then archive this XML for 5 years as it will be the fundamental document if there is an audit.
This is a complex business process change; the process will impact your ERP system configuration; so don't wait until the last minute -- contact a solution provider today before the other 500,000 companies do. You definitely don't want to be last in line during this transition.