Investigation

A digital services purchase split into two invoices, and the paperwork never quite lined up

Specification, warranty and asset-register records for one contract disagree on what was bought, when, and for how much.

By Farah Iskandar · 29 June 2026 · 6 min read

Case names, entities and officials in this report are composite and illustrative. References to public bodies describe their statutory role only.

A purchase in two parts

In September 2025 the Perak Digital Services Unit issued a purchase order to Rentas Systems Sdn Bhd for a case-management platform intended to replace a decade-old records system across four district offices. The purchase order, valued at 1.6 million ringgit, was split into two invoices roughly six weeks apart: the first for software licensing and implementation, the second for what the unit's own purchase file describes only as 'associated services.'

Splitting a single procurement into two invoices is not, on its own, irregular; unit finance guidelines allow phased billing tied to delivery milestones. What this report examines is whether the two invoices for this particular contract map onto any milestone the unit's own procurement file describes, and whether the specification the unit approved matches the platform that was ultimately delivered.

The old records system it replaced had been flagged in the unit's own annual technology review for three consecutive years as due for replacement, and the case for modernisation is not in question here. What is in question is the completeness of the paper trail the unit kept as the replacement contract moved from specification to delivery to payment, and whether that trail lets an outside reader follow the same path the unit's own auditors would.

The specification that arrived late

The technical specification attached to the purchase order is dated 8 September 2025 — the same day the order itself was issued. Procurement guidance published by the unit states that a technical specification should be finalised and attached before, not simultaneously with, an order's issuance, precisely so that bidders and the eventual supplier are working from an agreed document rather than one still being drafted.

A revised specification, filed as an appendix rather than a formal addendum, appears in the procurement file dated 19 September — eleven days after the order was placed and after Rentas Systems had already begun implementation work, according to the project's own kickoff record. The revision changes the required number of concurrent user licences from 150 to 220, a difference that would ordinarily affect price. Neither invoice reflects a licence-count change; the unit's file does not explain why.

Kickoff records reviewed for this report show implementation staff from Rentas Systems on site from 10 September, two days after the order was issued and nine days before the specification appendix was filed. Working from a specification still under revision is common enough in fast-moving technology contracts, but it is the kind of practice a procurement file is meant to document explicitly rather than leave to be pieced together from a kickoff log and an appendix filed separately.

Warranty terms and the second invoice

The purchase order's standard terms specify a twelve-month warranty covering defect correction from the date of final acceptance. The second invoice, covering the 'associated services' component, includes a line item described as 'extended support, months 13–24' billed at the point of the second invoice rather than at the twelve-month mark when the original warranty would have expired.

Billing extended support before the base warranty period has even begun is unusual, though not addressed by any rule in the unit's procurement manual, which is silent on the sequencing of support billing relative to warranty periods. The practical effect is that the unit paid, within six weeks of the contract's start, for a support period it would not need for over a year, a timing choice the file does not explain and that shifted a later-year cost into the current budget cycle.

The unit's finance office, asked in general terms about the sequencing of support billing during preparation of this report, said that phased billing tied to project milestones was standard practice across its technology contracts, without addressing the specific twelve-month gap between the support period billed and the support period the base warranty would still have covered. That general answer does not resolve the specific timing question this report raises about this contract.

Asset registers that disagree

The unit's fixed-asset register lists the platform as a single capitalised asset valued at 1.6 million ringgit, matching the combined invoice total. The state-level digital asset inventory, a separate register maintained by a coordinating unit and populated from returns each department files quarterly, lists the same platform at 1.1 million ringgit — a figure that matches only the first invoice, for licensing and implementation, and excludes the second.

A gap between a department's own asset register and a state-level inventory populated from that department's own quarterly return points to a reporting step, not a spending decision, as the likely source of the discrepancy; the 500,000-ringgit difference was either omitted from a quarterly return or captured under a different line item. Both registers are internal management records rather than externally audited figures, and this report was not able to determine which, if either, the unit itself considers authoritative.

State-level digital asset inventories exist precisely so that a reader outside any one department can compare declared technology spend across units on a common basis; a mismatch of this size, in a single line item, undermines that comparison for this contract regardless of which figure eventually proves correct. Neither register carries a note flagging the other as inconsistent, which suggests the discrepancy has not yet been identified internally rather than resolved and simply left unrecorded.

What a reader can check

Four documents anchor this report: the original purchase order and specification, the 19 September specification appendix, both invoices, and extracts from the two asset registers described above. All were obtained through the unit's routine disclosure channel. None required any restricted access, and a reader who wants to verify any figure cited here can request the same documents using the reference numbers listed below.

The unit has not disputed the accuracy of any figure in this report when approached with a summary of the discrepancies ahead of publication; it stated that a reconciliation of the two asset registers was scheduled for the current quarter but did not provide a date. This report will note the outcome of that reconciliation, and any figure it corrects, when it becomes available.

Reading a procurement file end to end

Individually, a same-day specification, a delayed appendix, an unusual support-billing sequence, and a register mismatch are each explicable in isolation — procurement files routinely contain small timing anomalies that reflect nothing more than administrative sequencing. Taken together across a single contract, however, they leave a reader unable to reconstruct, from the unit's own published records, exactly what was specified, when it changed, what was delivered, and what the platform is now worth on the unit's books.

That inability to reconstruct the full picture from public documents alone, rather than any one anomaly, is what this report sets out to describe. It does not allege that any figure was misstated deliberately, and the unit's own explanation — that a reconciliation is pending — may resolve some or all of the gaps identified here once it is published.

A specification that arrives the same day as the order it governs is not automatically a problem, but a reader has no way to tell the difference between a routine timing quirk and something worth a closer look unless the file explains itself.