FoAM Kernow accounting update 2019, the "Making Tax Digital" edition.

One of our biggest (and unfortunately entirely unpaid) research projects is administration. Accounting in particular is interesting from a range of angles, as a kind of cultural probe into the current state of what society considers important - but also as seemingly the single thing that very powerful white men loose lots of sleep over.

Recently the UK Government decided to require all companies to issue their VAT tax returns, and eventually all similar reporting via an online service (API), rather by filling in a simple form. This initiative, called "Making Tax Digital" I predict (along with many others) is going to make a lot of people very upset, cause a lot of mess, and is probably destined to be rolled back to some extent - as it requires that everyone use software that they have allowed to access their system. This essentially requires government mandated software, and makes free/open source tools for accounting very difficult, despite being "supported" by the same department.

This is what the fuss is all about, our Q2 2019 VAT return, checked and ready to clike the "Send to HMRC" button to upload it to the central government database:

For us this is actually a mixed situation. Previously we have used Gnucash for all our accounting, but this was starting to become a limitation as it's difficult to share work between multiple people - and I never figured out how to set it up for our partially exempt VAT reports properly, so our quite complex returns were always "hand made" in spreadsheet form using exported data.

So enter Odoo. This is a "mostly" open source project on the .gov.uk list - and can either be run online both in free or paid versions, depending on how much you need it to do, or as a community version, be installed on your own server.

We decided to start with the online version to get started quickly - but knowing that we can run it ourselves is a big factor. One of the problems we immediately noticed was that the documentation and online help doesn't really provide much in getting to grips with the fundamentals, as it either tends to be really high level brief descriptions that assumes a lot of prior knowledge, or answers to extremely specific questions on the help system.

Odoo uses a ledger system, which is a legal requirement for accounting in some countries such as Germany. In the past with Gnucash we've been able to enter data ourselves and tweak it until the accounts match the bank statement and then do reporting. With a ledger system you start with the bank transaction data, and all fixes and modifications to how this is classified have to be recorded so they can be audited at a later date, for example if you issue an invoice with a mistake on it, you need to make a new one with its own ID number to record what happened. In practical terms this means there is no undo or delete button, and you need to learn how to properly adjust mistakes you've made and attach notes to them so you understand it later. To begin with this was a real pain, but after a while you start to get to grips with it.

For initial setup we did this:

• Enter our company information.
• Create customers (all company data is searched and filled in automatically from public records, which is pretty handy).
• Set up the invoice layout.
• Enable multi-currency support for invoicing in Euros, and get it automatically downloading the exchange rates daily from the Bank of England.
• Add some new tax types - Odoo comes with the usual exempt, 0%, 5% and standard 20%, but as a non-profit, partially exempt oddity we also needed various types of "out of scope" categories which still need to appear on the VAT return in the expenses box. We probably only need one really, but for completeness we have three: 1. Out of scope purchase for project funded by grants (as we can't reclaim VAT for these). 2. Out of scope as the other business is not VAT registered, and 3. Out of scope as the purchase was made outside of EU. We also added an option for 19% VAT for things we buy in Germany for the Penelope project.
• Set up our own "Analytic Accounts" - one for each project that generates its own expenses, and one for "Studio Costs". These mean we can do accounting on a per-project basis, and it separate everything out nicely.

Once these are done (and, yes I had to do all of this several times before figuring it all out!) the quarterly routine can be summarised as:

• Import the bank statement data - either via connection to your online banking or via CSV. I ended up doing CSV import as you have more control of the exact dates used that way.
• Go through every transaction connecting it to its respective account depending on what it is, the type of VAT that has been applied to it (see below) and the analytic account for the project it comes from. Also I add a brief description of what it actually was to the text field.
• Each transaction needs the respective invoice added to a folder to be stored for the reporting quarter (photographs of paper receipts). We date them in the filename so we can find it again. I think you can upload them to Odoo and use Optical Character Recognition (or "AI" as the marketing calls it!) to read the invoice for you, but I haven't tried that yet.
• Fix mistakes when it doesn't add up (see below)
• When you have done this for the entire reporting period and there are no discrepancies, you can view the report that will be sent to HMRC and audit it, checking that the right transactions are put in the right places. I also tend to check the previous VAT return and look a bit closer at anything that is obviously different.
• Authorise the software with HMRC and submit - this step took a day or so to get the authorisation email, but it was pretty simple in the end.

VAT types for expenses

I have to look these up every three months, so in order to get that recorded here instead for future reference - these are some common expenses, the account they need to link to and their VAT status:

• Insurance: Insurance account, Exempt
• PAYE: PAYE account, no tax entry
• Salary: Directors remuneration, no tax entry (PAYE is already taken off)
• Subcontractor fees: Subcontracting account, tax depends if they are VAT registered.
• Rent: Rent account, standard 20% VAT
• Project expenses (materials, parts, electronics): Work in Progress account, usually either 20% VAT (depending on what they are) for a commission or out of scope if the project they are for is directly grant funded.
• URLs for new websites (internet and hosting), standard 20% VAT
• Tools, furniture etc: Office equipment, usually 20% VAT.
• Corporation tax: Corporation tax account, is tax so no tax entry.
• NSTF fees (irritating transaction fees on foreign purchases): Bank charges account, no tax entry.
• Train tickets: Travel and subsistence, 0% VAT.
• Hotels: Travel and subsistence, 20% VAT.
• Airbnb: Travel and subsistence, outside of scope if no VAT (as business is not VAT registered).
• VAT: HMRC VAT account, is tax so no tax entry.
• Printing costs: Printing account, 0% VAT
• Coffee: Office consumables, 0% VAT

Correcting mistakes

For most simple mistakes (e.g. mis-categorised items) I think the simplest approach is to "reverse" the transaction and make a brand new one, with a note to say why. One of the more complicated mistakes I made was to issue an invoice in Euros before I'd uploaded the exchange rate for the day the invoice was issued on! The exchange rate defaulted to 1 and I needed to keep the invoice ID, as it had already been issued - so I needed to add a transaction going in the other direction for the difference between the Euros value and the Sterling value. Tagging the debit side in the sales account as "Sales to EC" meant that this was subtracted from the amount that was reported to HMRC, making the value of the sales to EU box correct, based on the daily exchange rate.

This makes an entry on the ledger that looks like this:

Privacy and the cloud

Like all software, accounting software has recently undergone a shift from standalone use to the "cloud", and we've had some discussions here regarding privacy. As accounting data contains information that represents a legal liability, moving this (unencrypted) to someone else's computer has implications. Firstly using a "free" "software as a service" is not really free, as it means giving your data to a company in return for use of the service they are providing, so they can potentially collect it and sell it on for profit. This is Ok as long as you are aware of the transaction you are taking part in.

The most realistic threat here is accidental data loss - that we would have to pay the penalties to HMRC if for example, Odoo server went down and we could not file our return in time. To get around this you simply have to make plenty of backups - both in the database format they provide, as well as simpler CSV spreadsheets that could be more easily moved on to other software or used directly.

The other threat to think about is that it could be accessed by a third party - and this is just as much a problem if we were running the server ourselves. This brings with it two possibilities, one is that the data could be used to spoof identity in order to access our bank account (e.g. transactions details are sometimes used for security checks). This threat is probably minimal, as they are always part of a larger set of security details, and the accounting is usually out of date for this by the time we are collecting and reporting it. The second possibility is that someone may spot a mistake and bring HMRC to our door - we're also not worried too much about that one either (in fact we've requested an audit in the past but they didn't have time!).

Given all of the above it's only really the identity spoofing that stops us doing something we've discussed quite a lot - making all our accounting publicly accessible. This could be useful in a few different ways, one is transparency in terms of grant funding (particularly public funding, but also for charities), the other is a useful form of documentation for people wanting to set up similar organisations.

Why blog about this stuff anyway?

Why take the time to write all this down and spend even more time on administration than strictly required?

This kind of document can be used as evidence that we are following our rules and principles correctly in the future and our accountant has been encouraging about publishing our practices for this reason. In an area so complex and full of different interpretations and opinions, writing down and publishing your understanding of the rules and then following it shows that you are acting in good faith.