Top 5 Differences You Need to Understand - Using SAP ERP as a Baseline
One of the most common mistakes made in approaching electronic invoicing in Latin America is thinking that the process is similar to the European Union. Simply, EU eInvoicing is not the same as Latin American electronic invoicing. In this commentary, we
focus on the top 5 differences between EU countries and Latin American countries: specifically Brazil, Mexico and Argentina.
Key take-away: Latin America einvoicing will affect the configuration of your SAP ERP system, your ability to ship your product, and will require constant attention to keep up with the changing mandates.
1. In many Latin American countries an einvoice is mandatory –
Yes, in many of the EU countries, we are seeing governments requiring electronic invoices. However, this is specific to Business to Government (B2G) interactions. EU countries don’t dictate as a whole that you must send an approved electronic invoice for
Business to Business transactions or Business to Consumer transactions. Instead, the EU outlines functional requirements if you choose to send an invoice electronically. These functional lego blocks center around “authenticity and integrity.” In Latin America,
countries like Mexico require you to send a government approved electronic invoice if your organization meets certain criteria. For example, the newly announced legislation by Mexcio’s Servicio de Aministracion Tributaria (SAT) requires companies with annual
revenue of more than 2 million pesos to send electronic invoices.
2. Latin America requires a real-time, fully integrated process –
In countries such as Brazil, this is not just about applying a digital signature to a PDF and sending it to your customer via a portal and in parallel storing in a long-term archive. These are highly evolved, real-time integrations with the government
that can take 20 to 30 seconds for approval. In future blogs, we will explore the Latin American processes in more detail, but some of the most typical elements include: a defined XML schema via Web Services, a sequencing process, a printing process that
defines an output that must accompany the truck, designated barcodes on the print outs, archiving and more.
3. In countries like Brazil and Mexico, the electronic invoice approval is linked to your logistics process –
In other words, you can’t ship your product from your warehouse, until you receive the approvals from the government on your invoice. This can actually take many forms beyond just your ability to ship. In the worst case, the government can confiscate
your truck, the physical goods, and levy very strict financial penalties if the invoice information doesn’t match what is on the truck or what arrives at your customer. For example, in Brazil all the fiscal information and approval information must be printed
on a DANFE that accompanies the truck. This is also the reason why you should always have real time, local language support from your provider and a well-defined contingency process in place.
4. Latin America defines strict process standards – In Brazil, you have Nota Fiscal Eletronica 2.0 and in Mexico you have CFD v3.2 which clearly outlines the XML schema, integration touch points, process, archiving, and printing procedures.
Most of the EU regulations will dictate what makes an invoice VAT compliant, but they don’t mandate a specific format like Brazil or Mexico. Also, it should be noted that Latin American countries tend to expand upon these process standards, so be prepared
to adjust the XML and process during the year.
5. Latin America einvoicing will affect your SAP ERP configuration –
The solutions required to comply in Brazil, Argentina and Mexico require configurations and many times specific localizations to the ERP system before you can even send an electronic invoice. In Brazil, organizations must ensure that they have not only
installed and localized the taxes and fiscal information correctly (which by the way is no easy task), but they also must comply with SPED, Sistema Público de Escrituração Digital, reporting requirements.