AccAnalysisAccAnalysis
Media, Marketing & Communications

Two companies, one platform, and controls built in the first wave

A programme to replace a vendor-hosted product with an on-premises platform covering HR and payroll, finance, resource planning and IT administration for two related entities — designed to stand up to an annual IT-controls audit for three years.

At a glance
Status
Initiating
Region
Pakistan
Engagement model
Dedicated team, monthly

Status: Initiating. This is a programme we have scoped and priced, not one we have completed. It is published because how a firm plans a build is worth as much to you as a finished story — and because the plan is specific enough to argue with.

The organisation

Context

An advertising and communications group of roughly 100–250 staff across three offices, operating as two related legal entities. The group belongs to a larger international parent and is therefore in scope for an annual IT-controls audit.

It was running on a vendor-hosted third-party product and wanted to move to its own on-premises server, with no proprietary licensing that would block a future hand-over.

The brief

The problem

  • The existing platform was hosted and controlled by a vendor, with the group's data and release schedule sitting outside its own governance.
  • Two entities needed one system, but payroll runs, financial reporting and employer branding had to separate cleanly and provably.
  • Payroll rules were genuinely bespoke to the jurisdiction and changed with statute — and finance needed to change rates without involving a developer.
  • Controls the auditors test — separation of duties, privileged-user registers, append-only audit trails, developer-is-not-deployer release approval — did not exist as system capabilities and could not be evidenced on demand.
  • Evidence for the annual audit was being assembled by hand, under time pressure, once a year.
The work

What we proposed to build

Configure first, build only what is genuinely bespoke

Roughly four-fifths of the platform is configuration of open-source ERP modules that already exist and are already audited in production elsewhere — HR, accounting and the general ledger, projects and timesheets, asset registers, access control. Effort concentrates on the fifth that isn't: the jurisdiction-specific payroll engine, a desktop activity-monitoring agent, native mobile self-service apps, and the built-in audit reporting pack.

A payroll engine finance can maintain

Slab tables held in the interface with valid-from dating, change logging and maker-checker approval, so a rate change is a finance task rather than a development ticket.

Foundations before features

Record-level permissions, an inspectable permissions matrix and an append-only audit trail stood up in the first wave, so everything built afterwards inherits them instead of having controls retrofitted at the end.

Evidence as a by-product of shipping

Three environments, an approval-gated deployment pipeline where the developer cannot self-approve, and seven built-in audit reports — user listings, role and permission listings, access change history, privileged access, deployment log, audit-trail extract, leaver reconciliation.

Native mobile on the ERP's API

Leave, timesheets, approvals, payslips and directory as real iOS and Android apps rather than a web wrapper, with each entity's branding carried through to payslips and letters.

Method

How it is sequenced

  1. 1

    Foundations wave

    Environments, repositories, approval-gated pipeline, role matrix, record-level permissions, append-only audit trail.

  2. 2

    HR pilot

    One entity, on top of that machinery, so the first thing the client sees is also the first piece of audit evidence.

  3. 3

    Overlapping module waves

    While one module is built, the next is in discovery and the previous is stabilising. The client team gets hands-on sandbox access to each standard module before its wave begins.

  4. 4

    Accounting at a period boundary

    The finance switch-over is timed to a fiscal boundary, with opening balances migrated and one parallel period run.

  5. 5

    Parallel payroll run at go-live

    The old and new payroll calculated side by side before the old one is retired.

  6. 6

    Audit support as an ongoing service

    Walkthroughs, evidence and findings follow-up, with one named technical lead across all three years.

Sequence

How it was phased

PhaseDurationWhat happens
1Discovery & foundations
M1

Environments, CI/CD with approval gates, access control, audit trail

2HR & payroll
M1–M3

Pilot, build, parallel payroll run, stabilise

3Finance & accounting
M2–M4

General ledger, chart of accounts, statements, opening balances

4Resource planning
M3–M5

Briefs, milestones, allocation and utilisation from real timesheets

5IT & administration
M4–M5

User lifecycle, asset register, access recertification

6Mobile apps
M4–M6

Native iOS and Android self-service

7Stabilisation & hand-over
M5–M6

Go-live, recovery plan, documentation

Core build 5–6 months in overlapping waves; audit support continues as a service.

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The platform on its own servers
  • All source in its own repositories
  • The permissions matrix
  • The seven audit reports
  • Control documentation
  • The payroll rule set with its change history
  • Every log and repository transferred in usable form on exit
Stack
Odoo CommunityPostgreSQLPythonNative iOS & AndroidGitHub Actions with approval gatesOCA audit-log
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.