The commercial claim is that TaxChad is deterministic: teach it a rule once and it applies that rule, visibly, forever. This page is that claim taken apart, because a claim about determinism is worth nothing unless you can see the mechanism.
A rule matches on the transaction description, and optionally on the payment reference as well. There is no fuzzy matching, no similarity score, no confidence value and no model in this path. A rule either matches or it does not.
| Match type | Behaviour |
|---|---|
| contains | Case-insensitive substring. The default, and the one most rules use. |
| word | The text as a whole word, on word boundaries. |
| all_words | Every word present, in any order. |
| starts_with | The description begins with the text. |
| regex | A case-insensitive regular expression, for the cases the other four cannot express. |
On top of the text match, a rule can narrow by amount range (compared on absolute size, so it works on money in and money out alike), bank account, date range, currency and direction. Every condition set on a rule must hold. A condition left blank never narrows anything. An invalid pattern, such as a malformed regular expression, marks the rule invalid so it can never fire rather than throwing at the worst possible moment.
Determinism is not achieved by having rules. It is achieved by having exactly one answer to "which rule wins", in every case, forever. The engine sorts the client's rules and takes the first one that matches in full.
An explicit number, defaulting to 100, lowest first. This is the knob a user turns when a specific rule must beat a general one.
The user's own arrangement within a priority band.
Oldest first, so an established rule is not displaced by a new one added carelessly.
The final tie-break. It exists so that two rules which are identical in every other respect still have a defined winner. Ordering comes from this comparator, never from whatever order the database happened to return rows in.
A rule can carry a from date and a to date, tested against the transaction date rather than today. That is what lets a client change how something is coded from a given month without rewriting history, and it is why replaying a prior year gives the same answer it gave at the time.
TaxChad uses machine learning in exactly one place: turning a picture of a document into text and rows. It is never used to decide how something is coded, and the boundary is architectural, not a policy someone remembers to follow.
A PDF bank statement or a photographed receipt goes to document text extraction, which returns dates, descriptions and amounts. Speech to text turns a spoken invoice into a draft.
Extracted rows and drafts are presented for review. Nothing extracted posts to the ledger without a person confirming it.
No model chooses a nominal code, a VAT treatment, a tax box or an add-back. Those come from the rules engine and the tax engines, which are ordinary, inspectable code.
It would be easy to market TaxChad as "no AI" and easier still for that to be slightly untrue. The honest and defensible sentence is the one we use: the engine that decides is rules-based and deterministic; document text extraction is automated and always reviewed; no model makes an accounting judgement; a human reviews everything the machine produces. The extraction providers are named in the privacy policy and in the subprocessor register, because they process customer documents.
This is the part a general-purpose bookkeeping tool does not have and a practice cannot buy off the shelf. It is also the part that took fifteen years of domain experience to specify correctly, and the reason the founder being an accountant matters more than the founder being an engineer.
Computation from the ledger with disallowable add-backs handled as engine rules rather than notes: entertaining, depreciation, and the rest. Accounts and the return are prepared and filed by the regulated accountant, with direct integration to the accounts production tool on the roadmap.
Full trade box mapping on every income and expense code, cash basis by default with accruals opt-in, so a quarterly update is a grouping of the ledger rather than a separate return.
A separate tax source with its own box set. Residential rent is exempt so property codes post gross, and mortgage finance costs are treated as a basic-rate reducer rather than a deduction. A buy to let payment splits three ways: interest, capital and overpayment, with an annual true-up against the lender's certificate.
Deductions handled as a layer on the trade source rather than a separate source, with both sides carried: suffered as an asset, payable as a liability, and the domestic reverse charge for VAT handled separately.
A disposal event model rather than a ledger nominal, consuming transactions flagged as capital. Pooling, the thirty-day matching rule, the annual exempt amount and private residence relief are all engine rules.
Dividends, employment figures, foreign income with currency conversion, fixed assets and depreciation schedules, and payroll billing. Partnership is deliberately not built.
The box mappings were built against published professional guidance and verified by the founder in his capacity as a named reviewer of the underlying tax material, with any area lacking a verified source flagged in the specification as needing verification rather than shipped quietly. Where a rule was found to be wrong, such as an early draft putting property finance costs in the wrong box, the correction is recorded in the specification alongside the original error.