The UK Tax Drag editorial process is a six-stage workflow: (1) research from primary sources, (2) editorial drafting with embedded citations, (3) calculation verification against HMRC tools or worked examples, (4) review by the Editor against primary sources, (5) publication with a visible review date, and (6) a recheck of affected pages after each Budget and at the start of each tax year. The site is written and edited by one person, the Editor. The process is the same whether the output is a 300-word explainer, a 3,000-word deep-dive, or a calculator with embedded JavaScript logic.
Stage 1 — Research from primary sources
Every page starts with primary-source research. Secondary commentary (Money Marketing, FT Adviser, mainstream personal finance sites) is read for context but never cited as authority. Primary sources we use:
- HMRC manuals (Cryptoassets Manual, Pensions Tax Manual, SDLT Manual, Capital Gains Manual, etc.) for tax position.
- GOV.UK guidance pages for current rates, thresholds, deadlines.
- Primary legislation (Finance Acts, Taxation of Chargeable Gains Act, Income Tax Act, Pension Schemes Act) for definitive position.
- OBR Economic and Fiscal Outlook for forecast data.
- ONS for wage, inflation, and demographic data.
- FCA Handbook for regulated-product rules.
- The Pensions Regulator for occupational pension rules.
- NS&I for National Savings products.
- HMRC's CSV/JSON data for taxpayer statistics where applicable.
- First-tier Tax Tribunal and Upper Tribunal decisions for case-law on contested positions.
Each fact, rate, threshold, or allowance in the eventual page is annotated in the research draft with the primary source URL. If a claim can't be sourced to a primary, it's either reworded or removed.
Stage 2 — Editorial drafting
The page is drafted with the following structure (varies slightly by content type):
- Headline answer — the single-paragraph version of the page, designed for readers who only have 30 seconds.
- Worked example or specific scenario — concrete numbers showing the mechanic in action.
- Mechanics section — the rules in plain English, with the relevant edge cases.
- Common traps or mistakes — what real readers get wrong.
- Sources and methodology — primary-source links, methodology reference.
- Related guides — internal links to adjacent pages.
Tone: direct, opinionated where warranted, technical where necessary but never gratuitously jargon-heavy. We don't pad word count for SEO. If a topic can be covered in 800 words, we cover it in 800 words.
Pages are drafted, edited and coded with the help of AI tools. Every tax figure and rule in a draft is then checked against HMRC, GOV.UK or another primary source, and the Editor reviews each change before it is published. The editorial policy explains how AI is used.
Stage 3 — Calculation verification
For pages with numbers (which is most pages):
- Tax bands and allowances are cross-checked against the current GOV.UK pages.
- Worked examples are recomputed by hand from the published bands.
- Calculator outputs are checked against HMRC's published calculators where available, or against worked examples where HMRC doesn't publish a tool.
- Test cases — high-risk calculators have automated test cases in the
data/calculator-fixtures.jsonfile. The build pipeline checks them on every build viaverify-calculator-fixtures.js. - Edge cases — boundary cases (£0, £12,570, £50,270, £100,000, £125,140) are checked.
If a calculation differs from HMRC's tool, we investigate and either fix our calculation or document the deliberate methodological choice with rationale.
Stage 4 — Review by the Editor
The Editor reviews every draft against the primary sources before publication. There is no second editor: UK Tax Drag is written and edited by one person. The review covers:
- Accuracy of every quantitative claim against the cited source.
- Completeness — are obvious edge cases or counter-examples covered?
- Tone and clarity — does the page read clearly for the target audience?
- Internal linking — are appropriate related pages linked?
- Schema markup — is FAQPage, HowTo, Article schema correctly applied?
- Disclaimer language — is the not-financial-advice position clear?
Every page carries a byline crediting UK Tax Drag, with the date of the last review by the Editor. Where content in a specialist area (regulated pensions, complex tax planning, IHT) needs judgement beyond the Editor's experience, the page says so and points readers to a qualified adviser.
Stage 5 — Publication
On publication:
- The page is added to the sitemap and submitted to IndexNow.
- The review date in the byline is set to the date of the review.
- Schema markup (Article, Breadcrumb, FAQPage where applicable) is verified to match.
- OG image is generated for social sharing.
- Internal links from related pages are added (via the mega-nav or related-articles injector).
Stage 6 — Post-publication maintenance
Pages are rechecked on these occasions:
- After each Budget: calculators and pages whose rates, thresholds or rules are changed by the Budget are rechecked and updated, and their review date is refreshed.
- At the start of each tax year (6 April): affected calculators and rate-quoting pages are rechecked for the new year's figures.
- Triggered review: a page is rechecked when a reader reports an error, or when HMRC or GOV.UK guidance on its topic changes.
The review date in each page's byline reflects the most recent check. If you see a page with a review date more than 12 months old, please flag it via the contact form. Substantive corrections are listed with the date in the changelog.
How calculators specifically are maintained
Calculators are maintained like this:
- Automated test cases for high-risk calculators —
data/calculator-fixtures.jsonholds test cases (input → expected output) for calculators where an error is most costly, such as stamp duty and the investment reliefs. - An automated verification step in the build pipeline checks those test cases on every build.
- Documented methodology — each calculator page states its assumptions, and the methodology page explains the inputs, formulas and assumptions of the core calculators.
- A dated record of changes — substantive changes to a calculation are listed in the changelog.
When a Budget changes a rate, the shared constants file (data/tax-constants-2026-27.json) and the affected calculators are updated together, and the test cases are updated where a known answer changes.
What this process specifically does NOT include
- External review. All review is done by the Editor; there is no second editor, specialist panel or paid external auditor.
- Conflict-of-interest disclosure beyond Maze Tax Services. No other firm named on the site has a connection with the Editor that needs disclosure. If that changes, the editorial standards page is updated first.
- A fixed review calendar for every page. Pages are rechecked when a Budget, a new tax year or a reader report makes it necessary.