The hidden tax in your billing system: How manual auditing misses the tax revenue that automated validation can find

How do authorities think about business today? In the past, the conversation was about the tax rate: which band, which exemption, which good. Today, however, it's about the process. With more invoice information becoming standardized, being filed electronically, and being automatically reconciled by the authority, many times the authority can observe a transaction just as quickly as the entity raising the transaction. Compliance is no longer a task that finance completes prior to meeting a deadline. Compliance is now a strategic issue, and boards should address it accordingly.

While there is a significant improvement to the regulators’ ability to assess invoice data (which is viewed as a continuous and automated process), the same can't be said for most companies' processes of assessing their billing. Most entities still analyze their billing through traditional means: an occasional audit, a sampling of transactions, a reconciliation spreadsheet, and a somewhat nervous team during the week leading up to the filing deadline.

This difference in assessment processes represents a potential major risk. When an authority has clean and standardized data regarding a transaction and the company that generated the transaction has messy versions of that same data, then issues arise externally at a time chosen by neither party. This difference creates hidden tax revenue. An incorrect charge due to a post-contractual modification to a contract, unmeasured usage that was not charged, or improperly mapped tax treatment represent examples of individual defects that have two economic consequences: increased tax liability and quiet leakages.

Why manual audits miss these differences

Manual auditing is not meant to be an insult to auditors. The method of auditing simply doesn’t match well to identify errors. Manual audits involve random sampling therefore, they only identify errors that exist within the sample. Additionally, since manual audits occur on a schedule, errors occurring in the early days of a reporting period can go undetected for several weeks. Finally, since manual audits are generally conducted retrospectively, damage from incorrectly billed items is identified after the invoicing cycle has occurred. Additionally, manual audits rely heavily upon the group responsible for creating the billing rules to detect when those rules cease to apply.

In general, leaks are non-dramatic. Fraud occurs infrequently, and catastrophic errors rarely happen. Leaks typically result from tariff changes that reach multiple systems but not others; edge cases associated with bundles used infrequently; or revised rate plans that were not reviewed again. These types of issues are dull and only identifiable when someone reviews each transaction each time. People cannot conduct this type of review. Machines can.

Treat billing logic as software

Engineering discipline offers some lessons for finance. Billing logic is comprised of code, configuration and reference data; however, in many organizations it is modified with less regard than a website -- i.e., no version control, no automated testing, no gates for releasing into production and little to no monitoring once released into production. For years, software development teams have understood that quality could not be inspected-in at the end; quality must be engineered into the pipeline. The DevOps toolbox of continuous testing, automatic validation and rapid feedback applies nearly uniformly to billing.

Blueprint for Technical Teams

Below is a framework for developing a technical approach to managing billing logic based on nothing specific to vendors, platforms or countries and requires minimal resources:

1) Write your rules down as verifiable test statements. Contract language, tariff logic and tax treatment often reside in people’s minds and old e-mails. Place business leaders and engineers together in one space, document each rule as something machines can evaluate and store the resulting collection under version control similar to any other coding effort.

2) Validate at each handoff point. Usage leads to ratings which lead to invoices which lead to ledgers which lead to returns. At each step in the journey of a transaction, ensure that you compare each step against the previous one. Issues are detected sooner versus later.

3) Run your validations as part of your deployment process. Prior to deploying any change to a rate plan, tax mapping or reference data, validate your change against representative and adverse scenarios via automation. Do not deploy until all such validation passes. While simple, this one practice significantly reduces leakage prior to issuance.

4) Continuously validate against actual live data -- not only pre-deployment. Rules valid in March can become invalid in June without changing any lines of code -- simply because the world evolves. Exceptions should be placed into queues with names assigned and deadlines established versus in emails where they might get read.

5) Close-the-loop. Each exception proven real becomes another rule added to the library of test statements. Perform the review without finger pointing and note how quickly issues are discovered -- this is more important than how many are found. A team that identifies errors faster is improving regardless of whether their counts increase temporarily.

6) Let the evidence develop passively as a byproduct. Pipelines checking everything also create records of what was checked. When an authority or auditor requests information regarding compliance, it is likely already available in writing -- thereby reducing compliance into a frenzied event.

What Should Executives & Policymakers Ask For?

Digitizing invoices represented the initial required steps toward automating compliance -- it is not enough. Improved data does not equate improved internal compliance in the organization generating that data. Executives should place one simple question to their respective teams: "If a rule was modified this morning, how much time would we need to determine if our billing continued to adhere to the modified rule?" Policymakers should prefer solutions compliant with smaller organizations’ abilities and resources and not require smaller organizations to bear double expense for digitization efforts.

Long-term Viewpoint

For decades compliance and revenue assurance have existed independently -- separate function areas with separate budget allocations -- and this separation currently represents an expensive habit. Both depend on the same base: accurate billing validated continually and documented appropriately. Organizations able to establish this capability will experience decreased compliance expenses -- in addition to frequently finding additional monies previously unknown.

The regulator is reviewing every invoice. It is time the business does too.