Latin America continues to show why they lead the world in electronic invoicing. Below I cover the basics of the Chile eInvoice. Chile was one of the first movers in electronic invoicing and they have one of the more complex environments. The model is unique but does take into account some similar processes from other Latin America countries. As you look for solutions in the market place, be sure you understand Brazil, Mexico, Argentina and Chile which lead the world in eInvoicing adoption and usage.
The Chilean electronic invoicing model combines elements of the batch-oriented folio scheme used in the legacy Mexican CFD model along with the real-time communication as found in Brazil and Argentina. The process begins in two steps - first a delivery document (the “Gia Despacho” or “bill of lading”) is generated and registered with the government as the initial transport event, and then the other fiscal documents (like invoice or credit/debit notes) are generated and registered with reference to that event as follow-on activities occur later in the process.
Currently, there are 12 types of electronic fiscal documents, referred to collectively as “Documentos Tributarios Electrónicos” or DTE. Each document type has its own series of government issued folio numbers, which are consumed by the company in sequence as each DTE is produced. The fiscal data required for each document is packaged in a DTE specific XML format, and then signed and registered with the government in real time via web services exposed by the Chilean tax authority.
Additionally, at the end of each month, a set of up to four compliance reports are uploaded to the government web site, either manually or through automated web service. These reports summarize the DTE transactions produced during the month and specifically account for each folio used or destroyed as well. Folios can be skipped or voided through automated web service and any paper DTE’s issued in contingency must appear on these reports as well.
Customers registered for outbound DTE must be able to receive it inbound also. This involves providing a XML response back via email to the email address registered by the supplier on the SII website. There are currently no requirements for inbound fiscal compliance validation, though the XML structure fully supports it.
There have been a number of requests coming in to cover the basics for Brazil Nota Fiscal Inbound. Remember, that the validation of all inbound supplier Nota Fiscals is mandatory. Many companies are still accomplishing this manually. One company had over 15 individuals manually entering supplier invoices into the government portal. Another company had over 20. It is important to remember that you can automate and should automate this process. Below I discuss how you should focus on the Inbound process and the 3 types of invoices you will have to deal with: NF-e Goods, NF-e Service, and CTe – Transportation Invoices.
First it is important to distinguish what you have to do versus what you should be doing with the inbound XML in Brazil.
What you have to do I call – “Okay to Deduct” this consists of the required government validation of the XML and in Brazil, the subsequent posting of those codes to the SPED reports. It is also important to remember that the major change of “Recipient Acknowledgement” which is part of the Eventos legislation will be affecting many industries in 2013 and 2014. Currently, this process is required for Oil & Gas companies dealing with retail distribution.
And then there is what you should be doing, which I call “Okay to Pay”. The Brazilian model of einvoicing has created a unique environment to maximize the 3 way match process in Brazil. Many lead organizations are using the XML and the paper representation (called a Danfe) in order to simplify their inbound receiving process at the warehouse and automate the approval for payment of the invoice.
NF-e for Goods vs NFS-e for Services vs CTe
Goods Oriented NFE
Taxes assigned at State level, so much higher adoption and standardization
Digitally signed by emitter for non-repudiation and authentication to receiver
Electronic file is the legal invoice – paper visualizations for human comfort only
Invoices must be registered and approved before being sent
Printed DANFE must accompany goods in transit for validation en route
Inbound invoices must be validated and there are new "Eventos" processes taking place to eliminate ghost transactions.
Archive for 5 years by sender
Service Oriented NFS
Tax is assessed by Cities, so Integration Points are at City Level
Standardization came slowly but is advancing now (ABRASF followed by 50 cities, Sao Paulo migrating)
Can have many line items, but only one type of service per NFS.
Can deliver services and then invoice later, this is not a problem.
Can be withholding requirements for certain service types
NFS number and Return Code provided by the City
City calculates the tax for you – you make FI adjustments if needed.
City does the validation, buyer doesn’t have to worry about anything, except withholding, if applicable
Cancellations allowed within 30 days or 5 days after start of new month, whichever is earlier
Archive for 5 years by city
3 Types of Inbound City Level Connectivity
Fully Integrated Web Service - there are a number of cities that offer a fully functioning web service integration. This allows companies to use the web service to call the city system and download their service invoices directly into their environment.
Partially Automated -- there are a larger majority of cities that utilize this process currently. While they use a standardized format for the invoice collection, the actual triggering event is manual. Many of the customers' I work with will deploy a special ABAP extension that allows them to upload the invoice files directly into a staging table.
Manually - it is important to understand when working with city level integration that many of them are still in a manual mode. There won't be a complete way to automate these cities.
What is the CT-e:
Brazil Transportation Document – is issued and stored electronically in order to document the provision of transport services, whose legal validity is guaranteed by the issuer’s digital signature and authorization of use provided by the tax administration. Examples of use would be a Waybill (model 10) or an Invoice for Transportation Service (model 7 when transporting cargo).
The inbound process in Brazil is very complex because of the 3 types of invoices. Many vendors including the ERP vendors are not able to support the entire process – especially Service Invoices and CTe. Ensure you are working with someone that knows how to implement and ensure you are working with someone that understand how to take advantage of the process to simplify the 3 way match.
There is a definite trend for companies using SAP to move away from managing in house software solutions because of the maintenance difficulties imposed by the changing legislation in Brazil. Many companies looked at Brazil Nota Fiscal over the past few years as just another invoice process and compliance solution that could be managed by internal staff. However, as more organization move business processes into shared services and look to consolidate on single instances or regional instances of SAP, they are finding that the true cost of ownership is extremely high. Below are the two most common themes I see when speaking with customers looking to move away from an on premise Nota Fiscal solution:
Organizations have grown through acquisitions in Latin America, especially in Brazil over the past 5 years. Many of these companies that were acquired also ran SAP, but companies found themselves supporting multiple instances. As the IT team took on consolidation, they often realized that moving Brazil into a shared instance immediately opened their eyes to the real support costs of Nota Fiscal. It was not the XML schema or the web service connection – the real cost was due to the amount of changes coming from the government and the effect these changes had on SAP configuration. Rather than maintaining multiple FTE to research the changes, research how they should be implemented inside of SAP, and manage the constant flow of SAP upgrades; organizations have been turning to providers that eliminate this in-house problem. They have been turning to managed services that monitor the changes, understand how to implement them in SAP, and guarantee ongoing compliance of the SAP system and process under a fixed annual fee.
Another reason organizations are moving away from in house solutions is the regional expansion of compulsory electronic invoicing throughout Latin America. Most on premise software implementations only handle one country, leaving a global SAP team to manage multiple vendors in multiple countries. Supporting multiple FTE for day to day support, multiple boxes, multiple integration brokers, and a multitude of country specific solutions adds up to hundreds of thousands of dollars when viewed in the aggregate. A regional approach not only frees up IT budget, a regional approach also frees up needed IT resources. It is much more beneficial to have resources working on new value added projects rather than maintenance of a country process.
More simply stated: companies are moving to managed services because of the out of control cost to service the internal deployment day to day and more importantly manage the ongoing changes that happen every year.
In my last post, we discussed the key issues facing SAP accounts as the Mexico government continues to implement and push the usage of CFDI. I wanted to expand upon the potential issues facing Procurement and Accounts Payable users and managers as I feel it is an underestimated issue.
As discussed, 90% of invoices in Mexico today fall under the legacy regime of CFD which has a completely different XML schema and business process. And today, many companies will use manual data entry to comply with the inbound validations which are mandatory. Remember, the government announced on Dec 28, 2012 that the validated XML structure of the CFDI must be archived for a period of at least 5 years. And this XML will be used as the single version of the truth for auditors when reviewing VAT tax discrepancies. So here lies the problem -- an organization could see the inbound CFDI volume double if not triple. There is no way that manual processes will be able to keep up with the increased load so automation is going to be necessary. Here are some recommendations in the short term for AP managers or Shared Service managers looking at Mexico eInvoicing.
Ensure you’re compliant with the Dec. 28 2012 legislation for XML validation and archiving today. Many companies are not doing this process properly, and you need to be sure to get compliant regardless of CBB, CFD or CFDI invoices.
Understand the volume of CFD versus CFDI you are receiving today and will be receiving in the future as the government changes.
Understand how you are proving validations of the inbound documents - many PACs in Mexico still have very basic validations that don't cover all requirements.
Go beyond the "okay to deduct" which is the government validations of the comprobante and look into the "okay to pay" processes which will ultimately streamline your Inbound Receiving and Payables process. There is what you have to do, and then there is what you can be doing from the government mandates to streamline your operations.
Speak with vendors that specialize in Latin America eInvoicing and specifically the SAP system -- most Shared Services or SAP end users are moving to single instances or regional instances of the ERP system -- you need to know the effects of the changes on your AP process.
Last week while at the SAP Insider Financials conference I wrote about the “calm before the storm” – basically what will happen when the Mexico tax authority mandates the use of CFDI. As I stated in that blog, more than 90% of all invoices in Mexico are still on a legacy version called CFD, not the version of CFDI which requires real time government validations. In conversations with a few companies this week, I realized that organizations were not only unaware of this huge change; they also were unprepared into how to plan internally. So to net it out – there are five mission critical points you should plan for as you look at migrating from CFD to CFDI.
First and the most important: there are thousands and thousands of companies that will need to transition when the change takes place. You need to ensure you are starting conversations with your vendors soon in order to understand the level of effort, impact to your SAP system, and resource availability given the expected number of companies needing to move. My experience in these situations is companies who wait to the last minute will miss out on the deadlines imposed (Brazil Nota Fiscal 2.0 implementation and Mexico CFDI v3.2 July 2012).
Implementation –For an SAP account this will not just be a web service connection, it will be a change to your SAP system configuration.
Who will do this work – you, your SI, or does your CFDI provider take care of this task?
Will you have to manage a middleware (i.e. SAP PI) in order to exchange the IDOC with the CFDI provider?
How will you manage the integration of customer specific Addenda?
How will you manage the real time processes of printing, cancellations, et al…?
Monitoring – The CFDI process can affect your ability to ship just like in Brazil.
Will you have one single monitor in SAP?
Or will you have three separate monitors: one in SAP ERP, another monitor in the middleware, and another monitor in a 3rd party solution?
Maintaining –As the mandates take hold, they will not be static. They will be constantly changing and evolving. In the last 18 months, the Mexico SAT came out with multiple announcement. The most recent one required the buyer to validate and archive inbound XML (December 28, 2012).
Who will keep up to speed with the fiscal changes and the impact to SAP?
Accounts Payable Validation – Many companies are still validating there invoices manually with the Mexico SAT. This may be fine for a few XML per day. But when the government makes the changes to CFDI, your organization will see a dramatic increase in the amount of XML received. For most multi-nationals, the volume will require automation.
How will your organization address transitioning from manual validation to a fully automated solution internal to the SAP system?
This transition should not be overlooked – the question is – will you be prepared or one of the companies that waits to the last minute. Remember, failure in the compliance markets translates into fines, criminal penalties, customer collection issues and potential delivery/shipping delays.