Accounting software for UK practices

One system from the invoice arriving to the VAT return reaching HMRC.

A practice on Xero runs at least two subscriptions and often three: Xero for the ledger, Hubdoc or Dext for capturing purchase invoices, and something else again for the review checks that catch errors before a return goes out. Work moves between them by export, and the gaps between them are where mistakes live.

Zeynoc Ledger covers the whole job in one product: capture, the ledger, bank reconciliation, the review checks, VAT and filing.

What is built today The part nobody else does

There is nothing to buy and nothing to sign up to. The product is being written, and the section below says exactly how far it has got.

Status

The engine room is built. The application is not.

Software that handles other people’s tax figures should be honest about its own state, so here it is in full.

Built and under test

The database: Twenty schemas, with row level security on every tenant scoped table and the tenant context set per transaction, so a pooled connection cannot carry one practice’s identity into another practice’s query. The journal is append only by privilege rather than by convention.
The document extraction engine: It reads a UK purchase invoice from a PDF and finds the supplier, the dates, the reference, the three totals and a VAT rate for every line. A regression gate runs 200 documents on every push.
The queue and the object store: The queue is a table in the same database as the ledger, so enqueuing work rolls back with the business write that caused it and a redelivery cannot run a handler twice. Documents are stored under a key scheme written once, and a download link is signed for five minutes and good for a single use.
The audit trail: Hash chained per practice as rows are written, so a row altered afterwards fails verification rather than passing quietly.

Not built

Authentication: Nobody can sign in, because there is nothing yet to sign in to.
OCR: Most UK purchase invoices arrive as born digital PDFs with a real text layer, and those skip OCR entirely. A scan or a phone photograph needs an OCR engine, and that engine is not written.
The application: This page and two placeholder routes. No inbox, no reconciliation grid, no VAT return, no reports.
A measured accuracy figure: Extraction is held at 100 percent on a synthetic corpus, which is a regression gate and not an accuracy measurement: the corpus is generated from templates written alongside the extractor. Accuracy on real documents is unmeasured, and measuring it needs the OCR engine first.

Line level VAT

A VAT rate on every line, not one total for the document.

Capture tools stop at a single VAT total for the whole invoice. That holds up until a supplier puts standard rated and zero rated items on the same document, which is most stationery orders, most builders’ merchant invoices and every mixed grocery bill. The allocation back to rates is then keyed by hand, on the documents that take the longest to key.

Zeynoc Ledger assigns a rate to each line and solves the allocation arithmetically from the figures the document already carries. A penny difference goes to a rounding account, rather than a figure being adjusted quietly so the totals agree.

This is the one part of the product that exists today. It runs on born digital PDFs, against a synthetic corpus, and it has not yet met a scanned document.

One invoice, two VAT rates

A purchase invoice with three lines carrying two different VAT rates, showing the net amount, the rate and the VAT for each line.
Line	Net	Rate	VAT
Printer paper, 5 boxes	84.00	20%	16.80
Printed brochures	240.00	0%	0.00
Delivery	6.50	20%	1.30
Total	330.50		18.10

A tool that records one VAT total for the document hands the bookkeeper 18.10 against a net of 330.50. That is 5.48 percent, which is not a UK VAT rate and never was. Somebody has to split it back out by hand before the return is right.

One bill

One bill instead of three.

A ledger, a capture tool and a review tool are three subscriptions, three support queues, three sets of permissions to keep in step and three places a client’s records sit. The integrations between them are the part that breaks, and a broken export is invisible until a figure is wrong.

Pricing is not set, because the product is not finished and a price on an unfinished product is a guess dressed as a commitment. What is decided is the shape: one subscription covering capture, the ledger, the review checks and filing.

The plan

What it will do, none of which is built yet.

The list below is scope, not a feature tour. It is written out because a specific intention is worth more to a practice weighing this up than a page of adjectives, and because it can be held against us later.

Capture: Every client gets an email address. Invoices sent there are read, split if there are several in one PDF, checked against everything already posted, and queued for review.
Supplier memory: The first invoice from a supplier may need a correction. The system records where each field sat on the page and what you changed it to, so the second invoice from that supplier is near deterministic rather than a fresh guess.
Banking: Feeds through a licensed Open Banking aggregator, with CSV, OFX and QIF import as a fallback rather than an afterthought. Feed health is monitored, so a connection that goes quiet is reported rather than discovered at month end.
Reconciliation: Match, create, transfer and discuss. One to many, part payments, splits and transfers. Bank rules you control, with model suggestions ranked underneath them and never overriding them.
VAT: Standard, cash, flat rate, annual accounting, postponed VAT accounting and the domestic reverse charge. Boxes 1 to 9 derived from the journals behind them, with every figure traceable back to the source document, and submission direct to HMRC under Making Tax Digital.
Reports: Profit and loss, balance sheet, trial balance, aged receivables and payables, VAT reconciliation and a management accounts pack. More than two tracking dimensions, which is a limit practices hit in Xero and work around with a second product.
The practice layer: One dashboard across every client. Staff roles that span clients, review checks that flag duplicates, unreconciled items, missing attachments and VAT anomalies before a return goes out, and a field level audit trail showing who changed what and what it was before.

Timing

The first paying practice is roughly eight months out.

The delivery plan runs capture, then the ledger connection, then banking, then Making Tax Digital for VAT, then the practice layer. On two full time engineers with a UK qualified accountant reviewing the domain work, that puts the first paying practice at about week 36. The estimate is optimistic, because estimates are, and anything faster than that would be a claim rather than a plan.