Portfolio / 01 / Vertical system
Suriname, Aruba and Curaçao at launch, with Guyana built and following later. Each country has its own income tax tables, its own social premiums and its own year-end returns to file. The system keeps those separate, so the part an employer actually works with stays the same in every country.
Launching in Suriname, Aruba and Curaçao
Payroll software for employers in the Caribbean, covering the full cycle rather than the calculation alone. Employee records, salary components, leave accrual and balances, weekly and monthly runs, corrections against periods that are already closed, payslips, bank payment files, and the year-end returns each tax office expects in its own format.
Every employer is a separate client of the system, with its own data, its own users and its own accounts. Runs post directly into Zoho Books, so a company already keeping its books in Zoho does not end up reconciling a second system by hand each month.
The arithmetic is difficult on its own: brackets, ceilings, pro-rata, benefits in kind, pre-tax deductions, back-pay reaching into closed periods. That part at least stays put.
The harder problem is that the rules differ per country and are revised most years, while everything an employer sees has to stay the same. Suriname taxes overtime on a separate table; Guyana folds it into the regular one. Aruba applies a single annual ceiling of AWG 85,000 across two different premiums. Guyana grants a tax-free allowance of one third of monthly gross or G$100,000, whichever is higher, and calculates tax on a bonus by annualising it: work out the year with the bonus, work out the year without, charge the difference.
So a country is never just a switch somewhere in the settings. Each one is maintained separately — its tax tables, its premiums, its general-ledger accounts, its official forms — behind one shared way of working. Adding the fourth country did not mean reopening the parts that were already running, which is what keeps the cost of a fifth one reasonable.
Rates, thresholds and premium ceilings are settings, not software.
The client updates them in the administration screens. When a tax office publishes new figures in January, no release is required. Only a genuinely new rule — a relief that did not exist last year — needs work from us.| Countries | Suriname, Aruba, Curaçao and Guyana, each with its own tax tables, premiums, general-ledger accounts and year-end returns |
|---|---|
| Payroll cycle | Employee administration, salary components, leave accrual and balances, weekly and monthly runs, and corrections against periods that are already closed |
| Documents | Payslips, bank payment files, and the year-end returns each tax office requires, in the format it requires |
| Accounting | Direct integration with Zoho Books: chart of accounts, journal posting and reversal |
| HR data | Optional synchronisation with Zoho People, with differences reported for review rather than overwritten |
| Access | Separate interfaces for the administrator, the line manager and the employee |
| Security | Two-factor authentication, a complete audit log, and each employer’s data kept strictly separate from every other |
| Privacy | Employee anonymisation, per-employer export, and retention that respects statutory payroll-record obligations |
Before go-live we reviewed the whole system again: twenty rounds of testing, four detailed module reviews and two adversarial reviews of our own changes. Two of the findings are worth setting out.
Several hundred automated tests had been passing for months. The review established that they had only ever been run against a stand-in for the live system, and that the two did not behave the same way.
The consequence would have been serious. Past a certain number of employees the live system returns an incomplete result instead of reporting a problem. A large employer could have been paid in part, with nothing anywhere to show it had happened.
The correction itself was straightforward. The change that mattered was making the stand-in behave like the live system, so the same kind of failure cannot pass a test again.
Every payroll run posts a journal into Zoho Books. A journal that does not balance is rejected, and the month stays open.
Ours came to 16,092.50 against 15,700.00. The difference was exactly the employer's own share of the social premiums: the charges were recorded, but the matching entries had nowhere to go. We corrected the mapping, applied it to all four countries and to employers already set up, and made the internal report and the posted journal share one source, so the two can no longer disagree.
About forty smaller defects came out of the same review: corrections calculated from zero rather than from the previous run, employees excluded from their own final payslip after leaving, a year-end total that counted cancelled runs, allowances that reached the gross figure but never the net, severance charged twice in a December with weekly periods. All were found before anyone was paid.
We include this section because a passing test suite on its own says very little. Finding these took reading the system again on the assumption that something in it was wrong.
| Launch | Suriname, Aruba and Curaçao. Guyana is complete and tested against the revenue authority's 2026 schedule, and follows |
|---|---|
| Status | Built and audited, in preparation for go-live |
| Distribution | Direct, with a Zoho Marketplace listing prepared as an integration for Zoho Books |
Payroll is one example of a broader category: systems whose core logic is set externally, published as regulation, and revised on a schedule you do not control. Tariffs, levies, permits, subsidy conditions, compliance returns. If that describes your problem, we have built it four times inside one product.