Country profile packs: how we add a new country's tax engine in JSON, not code
Most payroll platforms hard-code one country's tax rules into their software. AnooreHR keeps every rate, bracket and statutory filing in a country profile pack — data, not code — so a new country is a configuration, not a release.
Ask a payroll vendor "do you support Ghana?" and the honest answer reveals how their software is built. If the answer is "we'd need to scope an engineering project," their tax logic is hard-coded — every bracket, every levy, every filing rule written directly into the application. Adding a country means writing, testing and shipping new code. That is why most payroll tools support one country well and everywhere else badly.
AnooreHR is built the other way around. A country's tax rules do not live in our code. They live in a country profile pack — a structured data file that describes how that country taxes salary: the PAYE brackets, the reliefs, the pension and social-insurance contributions, the statutory levies, and the filing schedule. The engine that runs payroll is the same everywhere. Only the data changes.
Why hard-coding tax rules is the wrong architecture
Tax law is not stable. It changes, and it changes on the government's timetable, not yours. When rules are hard-coded, every change is an engineering event:
- A budget introduces a new bracket → a developer edits the calculation, a reviewer checks it, QA tests it, and it waits for the next release.
- A relief threshold moves → same cycle.
- A new levy appears → same cycle, plus new filing logic.
Meanwhile your customers are already running payroll under the new rules, whether your release is ready or not. Hard-coded tax logic puts an engineering team on the critical path between a law changing and your software being correct. That is a bad place for an engineering team to be.
Profile packs move the tax rules off that path. Updating a rate is editing data, not shipping code.
What lives in a profile pack
A profile pack is the country's payroll rulebook, expressed as data the engine can read. In broad strokes:
| Section | What it describes |
|---|---|
| Income tax (PAYE) | Brackets, rates, tax-free threshold, reliefs, how taxable income is derived |
| Pension / social security | Employee and employer rates, the contribution base, ceilings |
| Statutory levies | Housing funds, industrial/skills levies, health insurance, and who pays |
| Filing calendar | What is remitted, to which regulator, on what schedule |
| Effective dates | When each version of the rules applies — so old and new rules coexist |
That last row is the one that matters most, and it's the one hard-coded systems handle worst.
Effective dates: two versions of the truth, side by side
Real tax changes have a date, not a switch. Nigeria's tax regime changed on 1 January 2026: payroll before that date follows the Finance Act 2020 rules; payroll from that date follows the Nigeria Tax Act 2025. A correct system has to hold both — because you still process corrections, back-pay and audits for periods before the change long after it takes effect.
Because profile packs are versioned by effective date, AnooreHR routes each payroll run to the rules that were in force for that period. Run December 2025, get Finance Act 2020. Run January 2026, get NTA 2025. No manual toggle, no "which mode are we in" question, no risk of computing an old month with new brackets. The data carries the date; the engine picks the right version.
The same engine, everywhere
The payoff of separating rules from engine is that the hard part — the payroll engine itself — is written once and reused. Proration, mid-month joiners and leavers, off-cycle runs, the journal that posts to the ledger, the payslip on the employee's phone: all of that is country-agnostic machinery that every profile pack inherits for free.
So when a new country comes online, it inherits a mature engine on day one. We are not rebuilding payroll for Ghana or Kenya. We are describing Ghana or Kenya to an engine that already knows how to run payroll — and then checking that description carefully against the country's tax code and a set of worked examples.
Where this stands today
Nigeria is live in production on this architecture, running full payroll under both the Finance Act 2020 and NTA 2025 rule sets, date-routed. The profile-pack model is exactly what lets us extend across the continent without a ground-up rebuild per country: the roadmap for Ghana, Kenya and beyond is authoring and validating profile packs, not re-engineering the product.
We hold ourselves to a hard honesty rule here: a country is only "live" when its profile pack has shipped and been validated against real calculations. We will not mark a flag green because the architecture could support it. The architecture is the reason we can move quickly — not a reason to claim we already have.
Does AnooreHR handle this?
Yes — profile packs are the core of how AnooreHR works. Nigeria runs live today, date-routed across the 2026 tax change, and new countries come online as validated profile packs on the same engine — no code release per country.
If you operate in more than one African country, or you're bracing for the next time your government rewrites the tax code, book a quick demo and we'll show you how a rule change becomes a data update instead of a support ticket.
Related reading: How to compute PAYE in Nigeria under NTA 2025 · One system, not three tools · BambooHR alternative for African SMEs
AnooreHR is free for teams up to 3.
PAYE, Pension, NHF, NSITF, ITF — all handled. No setup fee, no card.
Get started freePan-African payroll, HR, and accounting specialists. Every rate and rule is checked against the primary regulator before it ships.
More about our editorial team
