APIT Accuracy  ·  Y/A 2025/26

Why your APIT number
might look wrong

It’s almost never the math. It’s the inputs. Here are the things to check — with the numbers that show why each one matters.

A Humanised guide for SME owners & HR admins

First, the good news

The IRD’s tables do the hard part, and Humanised applies them automatically — no manual math. When an APIT figure looks off, the calculation engine is rarely the cause.

The tables are fixed

Rates, bands and constants come straight from the IRD 2025/26 tables. They don’t drift.

The engine is consistent

Given the same inputs, the result is the same every time — and traceable to a table and band.

Inputs are what slip

A wrong date, a missing pay run, a benefit not entered — that’s where almost every surprise comes from.

So this guide is a checklist of inputs — fix these, and the number is right.

Family 1

Data errors

What the system knows about the employee is wrong or incomplete. Seven things to check on every employee record.

01 Data error

The join date is wrong

APIT is annual, collected monthly. If the join date is wrong the system spreads tax across the wrong number of months — every monthly deduction is then too high or too low.

APIT uses the join date to know how many months of the year of assessment the salary covers. Put April when they really joined October (or the reverse) and every monthly deduction is calculated against the wrong span — building toward a year-end surprise.

Wrong

Joined Apr, system thinks Oct

6 months deducted

Rs. 48,000

Right

Correct: full year from April

12 months

Rs. 96,000

Fix it

Confirm each employee's actual first pay-period date in the year of assessment.

Table 01 · steady Rs.250k/mo

02 Data error

Prior pay runs for this FY aren't on the system

If earlier pay runs from this year of assessment aren't loaded, the system underestimates cumulative income — and misses the point where higher cumulative rules kick in.

Once cumulative pay for the year passes Rs. 1,800,000, the cumulative table (Table 05) takes over. If you start using Humanised mid-year without back-loading April-onward runs, the system thinks cumulative is near zero and keeps using the basic monthly table — under-deducting until the gap surfaces.

Wrong

Prior runs missing

thinks cumulative low

Under-deducts

Right

Real cumulative by Dec @Rs.250k

Table 05 applies

Rs. 27,000

Fix it

Enter every pay run back to 1 April so cumulative income is complete.

Tables 01 → 05

03 Data error

A previous employer's T-10 is missing

If an employee changed jobs mid-year, their previous employer's T-10 certificate must be loaded — otherwise this year's earlier income is invisible and tax is under-deducted.

When someone joins from another employer during the year, the law requires the second employer to account for the first employer's income using the T-10 deduction certificate. Without it, Humanised only sees the salary it pays — so cumulative income, and the band it lands in, are both understated.

Wrong

T-10 not entered

only new salary seen

Too low

Right

T-10 income added to cumulative

Table 05

Correct band

Fix it

Collect the T-10 from the prior employer and enter its income before the first pay run.

Table 05 · para 03

04 Data error

Non-cash benefits aren't captured

Company car, housing, utilities and similar perks are taxable ‘regular profits’ under APIT. Leave them out and the taxable figure — and the tax — are both too low.

The IRD counts the fair market value of non-cash benefits (housing, conveyance, electricity, telephone, entertainment and more) as part of monthly regular profits. They're not optional extras — they sit inside the number the table is applied to. Omitting them is one of the most common reasons a figure looks ‘too low’ until an audit.

Wrong

Cash only: Rs.200,000

benefits omitted

Rs. 3,000

Right

+ Rs.50,000 benefits = Rs.250,000

correct taxable

Rs. 8,000

Fix it

Enter the market value of every non-cash benefit as part of monthly remuneration.

Table 01 · para 02(ii)

05 Data error

No primary / secondary declaration on file

If an employee hasn't declared whether this is their primary or secondary job, the wrong table — and at worst the flat 36% rate — gets applied.

An employee can hold only one primary employment. With a primary declaration, the standard monthly table applies. Without one (or for a genuine second job), secondary-employment rates apply — and if the employee discloses nothing, the secondary employer must use the highest 36% rate. A missing declaration quietly pushes someone into the wrong regime.

Wrong

No declaration

highest rate forced

36%

Right

Primary declared

normal monthly bands

From 6%

Fix it

Make sure each employee files the right declaration; record second jobs explicitly.

Tables 01 & 07

06 Data error

Residency or citizenship flag is wrong

APIT routing depends on whether someone is resident and a Sri Lankan citizen. A wrong flag sends the calculation down the wrong table entirely.

Residents and non-resident citizens use the standard tables. Non-resident non-citizens, and residents paid by a foreign employer in foreign currency, follow different rules with different bands. If the residency or citizenship status is mis-set, the engine applies a table that simply doesn't fit the person — and the number won't reconcile.

Wrong

Status mis-flagged

wrong table chosen

Wrong table

Right

Status correct

right table & bands

Correct route

Fix it

Verify residency and citizenship status at onboarding and when circumstances change.

Tables 01 / 07 / 08

07 Data error

A mid-year salary change isn't reflected

If a raise or cut isn't entered when it takes effect, the system keeps deducting against the old salary — drifting off-target every month until corrected.

Monthly APIT is calculated on the actual remuneration for that month. A salary change that lands in payroll late means the wrong band is used in the interim. A big enough jump can also tip cumulative income over Rs. 1,800,000 — at which point the cumulative table should take over, but won't if the system still has the old figure.

Wrong

Old salary still on file

stale band

Off-target

Right

New salary entered

from effective month

On-target

Fix it

Record salary changes from the exact month they take effect, not the next pay cycle.

Table 01 (→ 05 if >1.8M)

Family 2

Routing errors

The numbers are right, but the payment went through the wrong table. Three to watch for.

08 Routing error

A bonus runs through the monthly table

A bonus is a lump sum and must use the EGAR method (Table 02), not the monthly table. Run on the monthly table, the figure is simply wrong.

Lump sums — bonus, arrears, leave encashment — are taxed by estimating your whole-year income (EGAR) and taxing the lump sum at the marginal rate that total reaches. That's deliberate: it stops a one-off being mis-taxed. Treating a Rs. 600,000 bonus as if it were a monthly salary applies the wrong bands entirely.

Wrong

Rs.600k bonus as ‘monthly’

Table 01 misuse

Rs. 122,000

Right

EGAR method on Rs.170k salary

IRD worked example

Rs. 36,000

Fix it

Flag bonuses, arrears and encashment as lump sums so the EGAR table is used.

Table 02 · Example 01

09 Routing error

A terminal payout isn't sent to Table 03

Retirement and end-of-service payouts — commuted pension, gratuity, compensation for loss of office, ETF — follow Table 03, with a mandatory IRD direction step.

Once-and-for-all terminal benefits have their own rules and retention rates, separate from regular pay. Beyond the calculation, the retiring employee must obtain a direction from the IRD within 90 days. Routing a gratuity through ordinary tables both miscalculates the tax and skips a legal requirement.

Wrong

Treated as ordinary pay

wrong rules + missed step

Non-compliant

Right

Table 03 + 90-day IRD direction

obtained on time

Compliant

Fix it

Identify terminal benefits early; the employee must get an IRD direction within 90 days.

Table 03 · para 04

10 Routing error

Foreign-employer pay isn't on Table 08

A resident in Sri Lanka working remotely for a foreign employer, paid in foreign currency, uses Table 08 — which has only two bands above relief, not the usual five.

This case is special: the employer is outside Sri Lanka, so no employer deducts APIT, and the employee self-pays via their own TIN. The bands differ too — relief, then 6%, then 15% on cumulative income — so applying the standard monthly table gives the wrong amount even before the self-payment mechanics.

Wrong

Standard monthly table

wrong bands

Wrong amount

Right

Table 08: 6% then 15%

self-paid via TIN

Correct

Fix it

Identify foreign-employer FX arrangements; the employee self-pays monthly via their TIN.

Table 08

Family 3

Timing errors

Right data, right table — but the wrong moment or period. Three calendar things to get right.

11 Timing error

The Rs. 1,800,000 cumulative trigger is missed

When cumulative pay for the year passes Rs. 1,800,000, deductions must switch to the cumulative table (Table 05) from that month on — miss the moment and the year under-collects.

Uneven income across the year — a few big months, or benefits pushing the total up — can quietly carry cumulative pay over the threshold even when any single month looks modest. From that month, Table 05 applies. If the switch doesn't happen on time, monthly deductions lag and the shortfall lands at year-end.

Wrong

Stays on monthly table

after crossing 1.8M

Under-collects

Right

Switches to Table 05

from the crossing month

True-up on time

Fix it

Watch cumulative year-to-date pay; the switch happens the month it crosses Rs. 1.8M.

Table 05 · para 05

12 Timing error

The year of assessment is misaligned

The APIT year runs 1 April to 31 March — not the calendar year. Align it to January and every cumulative figure and band threshold is computed over the wrong window.

Cumulative rules, the Rs. 1.8M trigger and the year-end true-up all depend on the year of assessment starting in April. Treat January as the start and you reset cumulative income three months early, mis-time the switch to Table 05, and produce figures that won't match an IRD reconciliation.

Wrong

Calendar year (Jan-Dec)

assumed

Wrong window

Right

1 April – 31 March

Y/A 2025/26

Correct window

Fix it

Confirm the system's year of assessment runs April to March before the first run.

All tables · Y/A 2025/26

13 Timing error

The March true-up isn't run

Some calculations use future months' expected pay, so small over- or under-deductions build up. The March true-up reconciles them — skip it and the year closes off-balance.

Through the year, lump-sum and cumulative methods estimate using remuneration still to come. Reality rarely matches the estimate exactly, so a gap accumulates. In March — the last month of the year of assessment — applying the cumulative table trues the whole year up. Without it, the employee over- or under-pays and has to sort it out themselves.

Wrong

No March reconciliation

year-end skipped

Year off-balance

Right

March true-up via Table 05

reconciled

Year balanced

Fix it

Always run the March adjustment so the full year reconciles before it closes.

Table 05 · para 04

Quick reference

Your accuracy checklist

Run through these before you question the number — most surprises are on this list.

  • Join date matches the real first pay-period
  • All pay runs back to 1 April are loaded
  • T-10 from any previous employer is entered
  • Non-cash benefits valued and included
  • Primary / secondary declaration on file
  • Residency & citizenship flags correct
  • Mid-year salary changes recorded on time
  • Bonuses & arrears flagged as lump sums
  • Terminal payouts routed to Table 03
  • Foreign-employer FX pay on Table 08
  • Cumulative-over-1.8M switch happening
  • Year of assessment set to April–March

Get the inputs right,
and the number takes care of itself.

Humanised applies the IRD 2025/26 APIT tables automatically — so once your employee data is complete and correct, compliance is handled. No manual math, no year-end surprises.

Need a hand auditing your setup? Call +94 76 443 7726

Last reviewed May 2026 against the IRD 2025/26 APIT tables. General guidance, not formal tax or legal advice.

Chat on WhatsApp