Summary

• OneView Commerce has signed a £141 million excluding VAT contract to provide new branch point-of-sale technology.
• The deal converts a procurement that was still unsigned on 17 August into an implementation programme involving configuration, testing, integration, and phased rollout.
• OneView and Accenture will occupy different parts of the replacement programme, making interfaces and accountability across suppliers central to delivery.

Post Office has signed a £141 million contract with OneView Commerce for branch-facing technology intended to replace part of the Horizon estate, moving a procurement that was still caught in standstill extensions earlier this month into the harder work of configuration, integration, testing, and rollout.

OneView Commerce will provide a new electronic point-of-sale platform across Post Office branches under an agreement worth £141 million excluding VAT. The company describes its underlying product as cloud-native and API-first, with support for counter transactions alongside mobile, customer-engagement, and self-service functions.

Programme planning is now under way, with the technology due to be configured, tested, and introduced in phases. Accenture has a separate role in the wider programme, taking responsibility for day-to-day Horizon operations during transition as well as work around back-end systems.

The signature closes one procurement uncertainty but opens several delivery questions. Techopia reported on 17 August that the OneView agreement remained unsigned after repeated extensions to the standstill period despite the supplier having been selected for the branch-system work.

A contract is only the start of migration

Post Office now has to turn a commercial software platform into infrastructure capable of supporting thousands of branches without reproducing the fragility and organisational dependence associated with the system it is replacing. Cloud-native and API-first architecture should make components easier to separate, although architecture labels alone do not resolve migration, data quality, integration, or governance.

Those issues carry unusual weight because Horizon is inseparable from the scandal in which faulty accounting evidence and institutional failures contributed to wrongful prosecutions and severe harm to postmasters. Replacing the software cannot repair those failures on its own, but any successor will be judged against a much higher standard of transparency, traceability, support, and contestability than an ordinary retail-technology upgrade.

A commercial platform can reduce some development risk by avoiding a system created entirely for one organisation and can provide a clearer upgrade path where the supplier maintains a core product used elsewhere. However, “off the shelf” does not remove the complexity around a branch estate that connects payments, cash, mails and parcels, partner services, accounting, networks, hardware, and central systems.

The multi-supplier structure adds another layer. OneView is responsible for the branch-facing platform while Accenture handles Horizon continuity and elements of the developing back end, making interfaces, incident ownership, testing, and release coordination as important as the quality of either supplier’s software in isolation.

Modularity changes the failure model

If the architecture works as intended, better-defined APIs and component boundaries should allow Post Office to replace or improve parts of its technology without treating the entire branch system as a single indivisible estate. That can reduce lock-in only where interfaces are documented, data ownership is clear, and the organisation retains enough technical capability to govern suppliers rather than merely coordinate them.

Those conditions are particularly important after a period in which technical information about Horizon, its defects, and its operation became entangled with contractual and organisational boundaries. A more modular architecture can make systems easier to inspect, but accountability still depends on people having authority to investigate discrepancies and challenge software output rather than treating it as inherently correct.

Phased deployment offers a safer path because faults can be identified before the entire branch network moves onto the new system, although it also prolongs the period in which old and new technology coexist. Running parallel estates and migrating groups of branches gradually can reduce the impact of a defect while increasing the coordination required during transition.

The signed contract therefore marks progress rather than completion. The next useful evidence will come from configuration and testing, followed by whether phased rollout produces a system that postmasters can understand, challenge, and rely upon while back-end replacement continues around it.