Tax Codes and EANs: A Match Made in e-Invoicing Heaven

I’ve written in the past about how e-invoicing will close the VAT gap, and in the process, change the world. I’ve also discussed why, despite the obvious benefits, it has been so difficult for companies to adopt e-invoicing on a mass scale--even though the technical capability to do so has existed since the 1990s.

We’ve made a lot of progress since then. Many countries in Europe and Latin America have enacted legal requirements for every company doing business there to do e-invoicing, which has done a lot to drive technology adoption. And, the technology continues to improve.

However, during all this time there has remained one small problem that has prevented companies doing business in countries with value added tax schemes from getting to 100 percent touchless processing: Tax codes.

These are just short letter-number combinations such as UK-1, UK-2 and so forth that identify a country, industry, type of good, VAT reclaim scheme, or other dimension of taxation. You need these codes to be able to pay your taxes properly in each jurisdiction where you are doing business. If you’re a global organization, you could easily have 1000 or more tax codes that you are dealing with.

Believe it or not, these short little codes have been the biggest obstacle to completely automating invoice processing. As an e-invoicing fan and evangelist, solving this problem has been on my wish list for decades. I’m pleased to have had the opportunity to work with the development and product management team at Coupa to finally develop a way to automatically assign the correct tax codes to incoming invoices, a capability which we have built into our latest release.

If you are familiar with the pain of tax coding, you will recognize that this is a major step forward. If not, come with me down the rabbit hole, and I will explain to you why solving this seemingly small, arcane back office problem will have so much impact.

Roles and Responsibilities
Let’s start by looking at the roles and responsibilities of the people that are involved, which I think is often the easiest way to understand a problem.

Outside of your company, you have suppliers, who are legally obliged to create an invoice when they deliver goods and or services, which includes the taxes that they are charging to the buyer. The date of delivery is usually what defines the date when the taxes are due for payment. The supplier transmits this information to the buyer and to the taxing authority and their job is done.

Inside your company, the buyer has to receive the invoices from the supplier, assess the content for accuracy and authenticity, and book those invoices into the accounting system to initiate payment.

Then, the finance department needs to create a whole lot of reports for the local taxing authorities. For example, if you're in Europe, then you need to create the Intrastat report, which gives the European Union an overview of the flows of goods and transactions across its 28 member states.

Then you need to create your VAT reports. These need to contain all the invoices received within a given month, in a specific format called the Standard Audit File, which you need to post electronically within a certain time period. Then you need to also create your VAT reclaim reports. Then you pay your taxes.

This is complex, detailed work, and ultimate responsible for the accuracy of that work rests with CFO. If any of this fails to happen, or if mistakes are made, it is the CFO that will receive the letter from the tax administration.

The Tax Coding Problem
Now, how do you get the data into your system accurately so that you can do all of this reporting and pay your taxes properly? This is where you run up against the problem of tax coding.

Your suppliers have raised invoices that contain a description of the products or services delivered, a VAT rate, and the resulting mathematically calculated VAT amount.

The basic problem is that the accounting or ERP system on the buyer's side doesn't work with VAT rates. It works with VAT codes. For example, a standard VAT rate in the U.K. is 20 percent at the moment. That is the information that the supplier puts on the invoice and uses to calculate the tax. The buyer then has to tag that tax with a VAT code such as UK-1, in their ERP.

This would be a much easier problem to solve if there were a standard set of VAT codes, but there isn’t. Different tax payers in different industries could have varying reporting requirements and also varying reclaim agreements with tax administrations around the world.

For example, if you are a large multinational with multiple product lines, you might have a special agreement with a tax administration in one country to reclaim 100 percent of the VAT charged to you for pharmaceuticals. You might have other agreements about pharmaceuticals with other countries, and different agreements in different countries for different types of products that you sell.

So, every company in the world has its own individual set of internal tax codes driven by their reporting requirements. In a large multinational company, finance will be dealing with hundreds or even thousands of tax codes.

These are tied to VAT code ledgers specific to the individual countries. These ledgers are almost like mini bank ledgers, because you will have to reconcile them and create a VAT report for each country that clearly shows the goods and services you have received that are subject to the UK-1 standard rate of 21 percent, and so forth.

The Mapping Problem
The problem has been to find an efficient, accurate way to map the inbound supplier invoice information into the tax code structure of the buyer’s ERP system so the data will dump into these individual account ledgers in order to automatically create the reports they need to pay the taxes correctly.

If you're a global organization receiving hundreds of thousands of invoices in all your different legal entities and you don't have a way to apply those individual invoice lines automatically to your internal tax code structure, at that point you have to touch every single invoice manually.

In some companies that is exactly what is happening. Someone is sitting down every day with a spreadsheet containing all of these tax codes and looking at the invoices and entering the data into the ERP system.

Or they could be using some functionality in their e-invoicing, but up until now no one has had a comprehensive and completely reliable solution, so finance still needs to check the work and handle exceptions manually.

They might also use some kind of external tax engine, but the problem with these has been that though they claim to be global solutions, they are each very good in some countries, but according to feedback I gathered from customers over the years, none are very good in all countries. You could do fractions of the work with different external service providers in different regions, but it’s going to be incredibly costly and it will still only cover part of your overall invoice volume, leaving a lot of repetitive manual work. In a large enterprise, it’s not uncommon to see upwards of 60 people devoted to tax coding, day in and day out.

As you can see, this is a multi-billion dollar problem that has only been partially solved, creating a bottleneck in the flow of information between otherwise integrated, automated systems, and in the global flow of money and goods.

The Solution
The way that we solved this problem is with a rules-based system that lets you configure your Coupa instance to map your internal tax codes to EAN codes, 13-digit commodity codes which, unlike tax codes, are standardized. These codes were transformative in their day, creating a global language that could be interpreted electronically.

Suppliers just need to add EAN codes to the PO and invoice, and we have also added the ability for them to easily do, so you do not need to burden the supplier in any way. The factual assessment of incoming supplier invoice content will match the EAN to the ledger on the buyer's side with the appropriate tax code and feeds the information into the correct ledger. This works for both compliant invoices and supplier-generated invoices, although for the latter there's an added level of scrutiny required. The best-case scenario is you have licensed compliant invoicing from Coupa, and you're deploying the country template so that you are receiving all of the necessary markers to automate the tax coding

You would be well-advised to have periodic reviews of your tax rates, configuration and mapping, but this is a massive enhancement to our product and unique in the market. It makes me very, very happy.