Privacy policy

Who we are

Making Tax Eazy Ltd is a company registered in England and Wales, company number 17380670, with its registered office at the address shown on the Companies House register. We trade as MakingTaxEazy. You can reach us at azhar@makingtaxeazy.co.uk.

Our registration with the Information Commissioner’s Office as a data controller is in progress, and the reference will appear here once it is issued.

We are software, not your accountant

MakingTaxEazy is a tool. It does not do your bookkeeping, prepare your accounts, or act for you. You — or your accountant — do the work; the software organises the records, applies rules, and shows you the result to check.

Where the software suggests a category for a transaction, or flags something for a second look, that is a suggestion you approve or reject. Nothing it proposes becomes a figure in a return until a person accepts it.

Controller and processor: what those words mean here

Data protection law uses “processing” in a much wider sense than everyday speech. It covers any handling of personal data at all, including simply storing it. Because your records sit in our database so the software can work, we process them in that legal sense — even though we take no part in your accounting.

Which of the two roles we hold determines who decides what happens to the data, and it is worth being precise about it.

For account holders — the people who sign in — we are the controller. We decide what we collect in order to run the service: your name, email address, and records of your use of it.

For the books and tax records inside the product, we are a processor. We hold and handle them on instruction and for no purpose of our own. Where an accountancy practice uses the software for its clients, the practice is the controller of those clients’ data. Where an individual uses it for their own affairs, they are the controller of their own.

The practical consequence, and the reason this section exists: we do not decide what happens to those records, we do not use them for our own purposes, and we do not share them with anyone except the providers listed below and HMRC when you instruct a submission.

Automated suggestions, and artificial intelligence

Categorisation is rule-based and runs on our own systems. It compares a transaction against rules — some built in, some learned from corrections you have made — and proposes a category. No third party is involved in it.

Some features use AI. Where they do, what the feature needs is sent to Anthropic, who operate the Claude models, and their model returns a reading or a suggestion. Each one runs only when somebody uses that feature. They are, in full:

• Reading a document — a statement, invoice, receipt, P60 or certificate, whether uploaded, emailed in or sent by WhatsApp. The document is sent, and the model returns the figures it found.
• Coding a document to the books— the lines the document was read as, with their amounts, the client’s chart of accounts, and how that supplier’s previous bills were coded.
• Commentary on management accounts— the business’s name and its statements as the software has built them: account names and figures across the months, and the checks the software has already run.
• Drafting a journal from a sentence — the sentence the accountant typed, and the accounts it concerns with their figures for the month and the year to date.
• Suggesting how accounts are grouped or where they belong in the statutory accounts— the business’s name, its account names, codes and figures, and, where there are any, last year’s year-end journals and their narrations.
• Changing how a report reads from an instruction— the instruction the accountant typed, and the report’s line captions and account names. No figures.
• Copying a practice’s own report layout — the layout of the workbook the practice uploads, with every figure in it replaced by a placeholder before it is sent.
• Suggesting which parts of a tax return apply — the short description of the client the accountant types in.

Bank transactions are not sent as a set, returns are not sent, and account holders’ own details are not sent. Three things about all of it are worth being plain about, because they are what the risk actually turns on:

• Nothing a model returns reaches the books on its own. A reading is stored as a record of what the model claimed to see, and a suggestion is shown to a person who accepts, changes or discards it. There is no automated decision-making with legal or similarly significant effects in this product.
• Anthropic act for us, on contract terms. Our agreement with them includes their data processing addendum. Under it they process what we send only to provide the service to us, they do not train their models on it, and they delete it from their systems within 30 days — except where the law requires them to keep it, or where a request is flagged as breaking their usage policy, in which case they may keep it for up to two years.
• It leaves the UK.Anthropic process outside the United Kingdom, so each of these is an international transfer of what is sent. It is covered by the safeguards described under “Where it is held”. Nothing else in the product depends on these features; a practice that would rather nothing left the UK can leave them unused.

This is being developed further.Where that means something new being sent to a third party, this section and the list under “Who else sees it” will say what and when, and we will tell account holders directly where the change is significant. Those two places are always the current position — if they do not mention a provider, we are not sending anything to them.

Where we develop our own understanding of how merchants map to categories, we do so from information that has been stripped of anything identifying a person or a business — not from your clients’ records themselves.

What we hold

• Account details: name, email address, and a hashed password. If you enrol two-step verification we hold the factor and one-time recovery codes, stored only as hashes.
• Bank transaction data you import or connect: dates, amounts, descriptions, merchant names and account identifiers.
• Tax information needed to prepare a return, which may include your National Insurance number, income and expense figures, property and self-employment details, and CIS deductions.
• Documents you upload, such as receipts and statements — and, where you asked for one to be analysed, the figures a model reported from it, kept alongside the document as a record of what it claimed to see.
• Technical data required by HMRC. To use HMRC’s APIs we must send “fraud prevention headers” with every call: your public IP address, device and browser characteristics, screen and window size, local timezone, and an identifier for your device. This is a legal requirement imposed by HMRC on all software connecting to their systems, not a choice we have made.

Why we are allowed to hold it

Where we act as controller, we rely on contract — we cannot provide the service without it — and on legitimate interestsfor keeping the service secure and working. Sending HMRC’s fraud prevention headers is a legal obligation arising from their conditions of API use.

Where we act as processor, our instructions come from the controller — usually the accountancy practice — under a written agreement.

Who else sees it

We use a small number of service providers, and we do not sell data to anyone or share it for advertising.

• HMRC — where you submit a return or an update, or where we read your obligations or calculations on your instruction.
• Supabase — database, file storage and authentication.
• Vercel — application hosting.
• Fly.io — network infrastructure in London that carries our connection to HMRC. It cannot read what passes through it, which is encrypted between us and HMRC.
• Xero — only where an organisation is connected. We read its records, and post to it only what a person has approved in the software: a bill, a payment, a journal.
• Anthropic— for the features listed under “Automated suggestions, and artificial intelligence” above, and only what each one needs.
• Postmark— receives documents emailed to a client’s inbox address and passes them to us, and sends the emails the software sends, such as a request for a missing invoice.
• WhatsApp (Meta) — only for a client who sends documents to us by WhatsApp. Meta carry the message and the document to us, and our replies back.

Where it is held

Your records are stored in the United Kingdom. What leaves it is the data a few named services need while they work. Our database and file storage are in London (Supabase, region eu-west-2), the application runs in London (Vercel, region lhr1), and the proxy carrying our calls to HMRC is in London.

The main exception is the AI features.What they send goes to Anthropic, who process outside the United Kingdom. That transfer is covered by the UK’s approved safeguards — the International Data Transfer Addendum to the EU standard contractual clauses, which is part of Anthropic’s data processing addendum. Everything stored in the product stays in London, including each document and what the model reported from it. Email passing through Postmark, a WhatsApp message through Meta, and a connected Xero organisation are handled by those providers on their own systems, which are not all in the UK.

One further qualification, because it is true and the first sentence would otherwise be too tidy: our hosting provider operates a global network that accepts your connection at a location near you before passing the request to London. The connection is encrypted throughout and nothing is stored outside the UK.

If that ever changes — if we use a provider that processes data outside the UK — the transfer will be covered by the UK’s approved safeguards, such as the International Data Transfer Agreement, and this policy will say so.

How long we keep it

Records relating to a tax return are kept for six years after the end of the tax year they concern, which reflects how long HMRC may enquire into a return and how long a taxpayer is required to keep the underlying records.

Account data is kept while the account is open and for twelve months after it closes. Where we are a processor, we return or delete data on the controller’s instruction, subject to any period we are separately required to retain it.

How it is protected

Access requires a password and a second factor; two-step verification is mandatory, not optional. Your HMRC access tokens are encrypted before they are stored. Uploaded documents are held in private storage that is not publicly addressable. Traffic is encrypted in transit.

No system is beyond compromise, and we will tell you and the ICO about a breach affecting your data within the timescales the law sets.

Your rights

You can ask us for a copy of your data, to correct it, to delete it, to restrict or object to what we do with it, or to have it sent to another provider. Write to azhar@makingtaxeazy.co.uk and we will respond within one month.

If your data is in the product because your accountant put it there, they are the controller and the request is best made to them; we will help them answer it.

If you are unhappy with how we have handled your data you can complain to the Information Commissioner’s Office at ico.org.uk, or on 0303 123 1113. We would rather you told us first so we can put it right.

Cookies

We set cookies that are strictly necessary to keep you signed in and to keep the service secure. We do not use advertising or analytics cookies, so there is nothing here to consent to or refuse.

Changes

If we change this policy we will change the date at the top, and we will tell account holders directly where the change is significant.