SAP e-invoicing Mexico CFDI PAC Strategies (Part 4 of 5) - Customers create Chaos

[former_member182834]

It should not be forgotten in this discussion around government XML standards and compliance mandates that the purpose of an invoice (electronic or paper) is to get PAID.

 

A few things that you need to be aware of concerning the distribution of the invoice, as it is not common for the PAC to do this work. It is more common for them to have you do all the work in preparing the XML, preparing the customer specifics, then pass to them for a signature, they then pass back to you to print, put on the truck and distribute to the end user.  A signature is just a small piece of the puzzle – make sure you cover all pieces of the puzzle including customer customizations and distribution.

 

By law you must make the government approved invoice (CFDI with Timbre) available to your end customer – below is what you need to know that is often overlooked concerning the customer and final distribution:

1. The CFDI XML has a special area called an Addenda – this is for an end buyer to request information to help them process the invoice. They can request this and put it into the XML.  Your issue will be that each of your end customers can ask for:

1. 
   
   
   
   1. a. A unique Addenda (Edifact, embedded PO # in plain text, another XML subset of segments)
   
   
   2. b. The PDF output can also vary per customer. It is common for large buyers to want something in the XML Addenda one way and the representation on the PDF in another way creating additional implementation and maintenance issues.
   
   
   
   

2. You must distribute the  XML invoice to your customer

1. 
   
   
   
   1. a. Sometimes this is email
   
   
   2. b. Often large buyers want a B2B communication such as AS2 with Walmart or SFTP or a Web Service
   
   
   
   

 

Take Away – customer requests create additional complexity in the process. This affects SAP master data, configuration, printing procedures, and most of all getting paid.

 

Customer Experience – they had over 20 addenda requests – it took them 3 months to develop with their inhouse teams and now every time there is a change to the SAP system, a customer has a request for a change, or the government changes – it becomes a 6 week project to integrate and test.  Don’t over look the chaos the customer specifics can bring.

 

Your customer will validate that invoice with the government to ensure that it is a valid XML and approve for payment

 

• 1. The first issue level of checks that your customer will do is called the “Okay To Deduct” step.  They are going to check to ensure that this is a legally registered CFDI with the SAT. They will also check the XML format to ensure that it is all proper. A customer will not want to pay an invalid government invoice as they can’t use that XML to deduct the supplier portion of the VAT from their remittance to the governments.

• 2. Your customer will then do a commercial compliance check called “Okay To Pay”. They will most likely check to ensure the taxes are correct and that it matches to a Purchase Order at the line item level and the Goods Receipt.

 

• 3. Important note: your customer can’t change an incorrect invoice – they must tell you the issue and you as the supplier either need to adjust with a registered Credit Note/Debit Note or cancel the CFDI and register a completely new invoice.  Regardless, all of this will delay your ability to collect payment and extend your DSO. If you are a public company and this happens at the end of the month or quarter for large invoices, this could affect revenue recognition.

Take Away: your customer will validate the invoice, they actually have to store your XML by law for 5 years according to the December 28, 2013 resolutions. Understand the distribution, and the processes for getting paid in Mexico under CFDI.  There are a lot of little things that can delay payment.

Customer Experience:  we have had clients come to me with the following problems

• The end customer won’t pay because the Postal Information in the invoice they sent was not the exact Mexico Postal Service registered format. This was an SAP Master Data issue.


• The end customer wouldn’t pay because of Unit of Measure issues


• The end customer wouldn’t pay because they wanted the Surcharge added into the invoice (problem is that the Mexico CFDI XML has no field for surcharge, this is called an Extended attribute and you must manage this)