Automating Partial Exemption

When I joined Arkk (nearly 9 months ago now!) my knowledge of Partial Exemption was whatever I could remember from the ACA, plus anything I gleaned from sitting next to the KPMG Tax Tech team who were in charge of (to be fair) the only piece of software that was good at automating Partial Exemption calculations. At the time. Not any more.

9 months later, I can (happily?) say that I speak reasonably fluent PX, having spent a good deal of my time out with clients understanding the complexities of VAT processes, and then working out how to solve them.

What we've ended up with is a pretty unique way of dealing with PX. No rigid templates. No "take our pre-built model and bend it to meet your actual model". It dawned on us very quickly that even 2 firms with the same type of method, actually likely have different methods. So, the concept of "out of the box" and PX don't really mix all that well.

Meet the for:sight approach to PX. This is an (anonymised for the purpose of LinkedIn...) process we built for a Bank that is submitting their first MTD submission via the HMRC API in the coming weeks. The below looks like a nicely designed data-flow diagram that your friendly, expensive, consultants might create for you - but no! This is actually the live design from the for:sight platform. This design is used in to define what the process is, and is then scheduled for the client to use for their actual return process:

And here are the steps that we go through:

1. Upload 5 files from their source ERP system directly into the tool. No manual intervention, just loading in Excel files.
2. Also upload a list of the FX rates to use for translation of USD/EUR figures [in the future we'll API these in, for ease]. Also upload a list of country codes and which Geographical Area they're in. As their ERP system used a few non-standard ISO codes, we created a custom one just for them.
3. Calculate the first cut of figures. This involves doing the FX calculation and adding in a column for "Area", based on their ERP country-code. It also renames headers to our format.
4. Their PX method has 2 main calculations. The first based on a split of staff time across 3 main sectors (Money market, Loans and Other) and the second based on the trades in the sales office (some Sales offices by volume of trade, others by value). So here we load in their timesheet data to work out the split between the sectors.
5. We upload their invoices as exported from a well-known accounting package. Again, no manual manipulation here, we take the source file as-is.
6. We then run our "Fix & Verify" step on the data, to check the Tax Coding given in the data. This identifies that Tax Code as the "target" and takes other data fields (supplier, cost centre, etc) and identifies inconsistencies in the Tax Code. These are then rectified, if required, by the user.
7. We then calculate the attribution of the Invoice VAT based on the two main ratios (staff, and trades), as well as applying a different rate to invoices from Bloomberg. This is where the main number-crunching happens.
8. We then calculate the 9-box return based on our defined data model.
9. Finally, we check the filing obligation with HMRC and file the VAT via the API.

Whilst the above looks complicated, the client was able to send over their data in a sensible Excel format, and was able to walk us through the logic they'd used. Total implementation time - 3 days. Total effort required by the client at quarter-end now? Run a few files from source and drop them into for:sight. It does the rest.

When we started this "journey", PX was "too complex" and "we'll do it via an adjustment". Adjustments are still entirely possible, of course, but actually, the power of our platform means that we're ready to automate the crazy world of Partially Exempt businesses...