Engineering Approach

The hard part is
being exactly right.

Enterprise software here fails on the same things repeatedly: statutory rules bolted on late, payments treated as an integration, and an assumption that the network is always there. This is how we build against that.

Regulation as code

In the core, not the config

Our first engineering commitment

Most enterprise platforms sold here arrive without local statutory logic, and a consulting engagement adds it afterwards. Every buyer funds the same rebuild. We put the rules in the product instead, which means a rate change ships as a release rather than a project.

  • Tax bands and contribution tiers held as product logic
  • Statutory schedules generated from posted transactions
  • Historic runs keep the rates that applied at the time
  • Rule changes reach every customer in the same release

In practice. CoreHR calculates PAYE, SSNIT tiers 1 to 3 and NPRA scheme reporting from the same records the pay run uses, so what is reported and what is paid cannot drift apart.

A shared foundation

We built the layers every platform would need before building the platforms. It is slower at the start and considerably cheaper afterwards.

Finance

Double-entry posting across entities and currencies, with intercompany elimination.

Compliance

Statutory calculation and reporting, shared so a change lands once.

Identity and access

Roles, permissions and approval limits applied consistently.

Workflow

Approval routing, escalation and service levels as configuration.

Payments

Mobile money and bank transfer at the transaction layer.

Integration

Documented REST APIs and webhooks on every platform.

Built for local conditions

Offline capable

Field and branch work continues without a connection, then reconciles on sync with duplicate detection.

Mobile money as settlement

Where part of a workforce or customer base has no bank account, that is the primary rail, not a plugin.

Low bandwidth by default

Interfaces are built to degrade gracefully rather than to assume fibre.

Deployment choice

Cloud, in-country data centre or your own premises, decided against your data policy.

Controls and data protection

Data Protection Act, 2012

Consent capture, purpose limitation, retention scheduling and subject access aligned to Act 843.

Maker-checker

Financially material actions require a second pair of eyes before they commit.

Immutable audit trail

Every amendment and approval attributable to a named user, with a timestamp that cannot be edited.

Code review and testing

Review on everything, automated testing and staged releases. Financial software earns that discipline.

Where our responsibility ends. Our platforms calculate from the data you post, and we keep the statutory logic current. The accuracy of that underlying data, and the submission itself, remain yours.

Delivery

How a deployment
actually runs.

Implementations fail on sequencing more often than on software. This is the sequence, including the point at which you can stop.

Discovery

Two to three weeks mapping your process and obligations. You keep the findings either way.

Configuration

Structures, rules and approval limits set to your operating model. No code fork.

Data migration

Balances and master data loaded and reconciled, signed off before anything goes live.

Parallel run

One full cycle side by side, so differences are explained before cutover rather than after.

Go live

On-site support, trained super-users and a documented rollback position.

Support

Accra-based, in your time zone, with statutory updates included in subscription.

Ask us how something works.

Technical questions get technical answers, from the people who wrote it.