It’s on Unifier

There is a standard answer to a late payment query on many large construction projects.

“It’s on Unifier.”

The phrase is offered as though it explains everything. It does not identify the person holding the payment, the decision still required, the amount in dispute or the date by which the contract required action. It says only that a digital record exists somewhere inside Oracle Primavera Unifier and has not yet reached the correct coloured box.

The contractor may have submitted its application. The supervision consultant may have checked the measured work, reviewed the supporting records and prepared its assessment. The amount may be known, largely agreed and ready for certification. The client team may even accept that payment should be made, but the record is on Unifier and, apparently, that is enough to stop the clock.

A piece of software has somehow acquired more authority than the client that bought it and the contract the client signed. Unifier is not the employer, the engineer, the contract administrator or the certifier. It has no duty to act, no contractual period within which to decide and no bank account from which to pay. Yet on many projects its workflow is treated as though it has a right of veto over all of them.

The contract says that an assessment or payment is due within a stated period. The software says that a box has not been ticked. Computer says no.

This is not merely a complaint about an old screen or too many clicks. It is about the way clients use enterprise software to push their own administration down the construction supply chain. The client selects the platform, sets the fields, controls the approvals and owns the reports. Contractors and consultants then prepare the records, enter the data, upload the evidence, correct the errors, chase the workflow and explain the delay.

The client gets a dashboard. Everybody else gets a second job.

A declaration of bias

I should declare a personal gripe with Unifier. I have had one for years, and it is not based only on being trapped on the user side of a badly designed payment and change management workflow.

Several years ago, I helped set up a Unifier platform for a public water utility. I worked through the forms, business processes, permissions, routes and reports from the administrative side, so I know what the system can do and how quickly poor design can make ordinary work far harder than it needs to be. I also know that many of the worst problems blamed on the software are created by clients that have badly designed, badly staffed or badly maintained their own implementation.

Unifier does not understand a construction contract; it understands fields, statuses, permissions and routes. Somebody must translate the real business process into the system, and that person needs to know who has authority, which date matters, what must be recorded, what can be returned, what can be partly assessed and what happens when the normal route fails. If the people designing the process do not understand payment, certification, change control and contractual authority, the result may be technically valid while making no commercial sense at all.

From the ordinary user’s side, the product feels barely changed from the system I used around 2017. The interface still looks old, clunky and needlessly hard to follow. Common tasks remain hidden behind menus, logs and forms which make sense mainly to people who already know where everything is. It has the feel of software preserved as a heritage asset, with each new release careful not to disturb the period features.

That would be irritating in any sector, but in construction it is worse because the industry is already slow to adopt new technology and many experienced engineers, quantity surveyors, site managers and contract administrators are not software specialists, nor should they have to be. Their value lies in knowing the work, the contract, the quantities, the programme and the records, yet they are given a login, a short training session and a workflow whose purpose nobody has properly explained. They are then told that failure to use it correctly may delay payment, approval or instruction.

People are not always resisting technology; sometimes they are resisting a poor system which has made a familiar task slower, less clear and more exposed to error.

The client bought it. Everybody else runs it.

The main point is simple: the client owns the platform, so everybody else is made to work as a branch of the client’s administration.

The contractor creates the payment record, selects the client’s codes, completes the client’s fields, uploads the files, answers workflow comments and resubmits anything the system rejects. The supervision consultant downloads the submission, carries out the assessment, prepares separate schedules, enters or uploads the result, routes it onwards and chases the client when the record stops moving. Both parties often keep their own registers because the Unifier view is not enough for daily commercial control, and they keep copies of the documents because access may change, users may leave and nobody wants the contractual history to depend on a client-owned portal remaining available forever.

The client receives the report and calls this a saving. It is not a saving but a transfer of work from the client’s payroll into the contractor’s preliminaries, the consultant’s staffing and, eventually, the client’s project cost. The hours have not disappeared merely because they are being worked by somebody outside the client’s organisation.

The position is even harder to defend where the fields exist only for the client’s own reporting. A client may want every payment mapped to portfolio codes, funding lines, asset groups, programme packages, internal approval limits and finance categories. That may be useful to the client, but it does not follow that the contractor or supervision consultant should provide unpaid data-entry services to satisfy it.

The contractor should submit the application and evidence required by the contract. The consultant should assess it and issue the record required by its appointment and the contract. Where the client wants the information renamed, recoded, split again and fed into its own enterprise platform, the client should employ people to do that work. The supply chain is not a free back office simply because the client has bought a licence.

A glorified document management system with extra steps

The sales pitch presents Unifier as a broad project controls and asset management platform. In theory it can manage cost, change, contracts, payment, approvals, funding, reporting and many other records. On many live projects, however, very little of that claimed capability is used in the payment process.

The contractor prepares the progress payment application in Excel, PDF or its own commercial system. The detailed measurement, bill items, change schedules, material records, invoices, timesheets, photographs and other evidence are compiled outside Unifier, then uploaded as attachments. The supervision consultant downloads those files and carries out the assessment in Excel or another specialist tool, prepares a separate assessment or certificate, and uploads that document as another attachment.

The real commercial work has taken place outside the platform. Unifier has added a record number, a cover form, a status, a route and several chances for somebody to return it. It has not measured the work, checked the quantities, read the evidence or decided what is due. It has carried a folder between digital inboxes.

In practice, it often becomes a glorified document management system with extra steps. Its main contribution is to make users type a smaller and less useful version of the attached assessment into mandatory fields so that a dashboard can display it. The attachment contains the actual commercial position, while the fields contain enough information to make the traffic light work.

The same amount is therefore prepared once, uploaded once, typed again and then checked against the file from which it came. This is not automation but transcription with a login, managed by a filing cabinet which can refuse to accept the file because the wrong option was selected from a drop-down list.

There is a reason users fall back on attachments, since construction payment is not one standard transaction. The assessment depends on the contract, method of measurement, bill structure, treatment of materials, retention, advance payment, changes, provisional sums, dayworks, taxes, currencies, deductions and previous certificates. A generic platform can only handle that properly where the set-up team understands the actual process and tests it against difficult cases, not merely a clean demonstration in which every user is available and every amount is agreed.

Too often, the real commercial process is left in Excel because Excel can deal with the awkward parts. Unifier is then used to record that the awkward work has happened somewhere else. Its most valuable feature becomes the attachment button.

When the workflow outranks the contract

The worst use of Unifier is not merely inefficient; it interferes with contractual administration. A client may begin to treat a system step as though it were an agreed term, even where the contract says nothing about the platform or does not make its use a condition of entitlement, certification or payment.

The contractor submitted the application, but not through the correct workflow. The consultant completed its assessment, but the record was not advanced. The certificate exists, but the client’s internal approval remains pending. The payment period has therefore apparently not started, or has stopped, or has entered some digital state in which ordinary time no longer applies.

The proper position will depend on the wording of the contract, and where the contract clearly requires submission through a named system that requirement must be followed. The problem arises when an owner-controlled workflow is allowed to add new conditions, new waiting periods or new excuses that the parties never agreed. The platform should support the contract, not quietly rewrite it.

On too many projects, Unifier is used as a procedural weapon. A project team may refuse to recognise a submission until it appears in the system, even though the document was received and the contract does not grant an extra period for data entry. A consultant may be prevented from issuing an assessment because a client approver has not acted. An undisputed amount may remain unpaid because one internal code is missing or a record has been returned for a clerical point.

No person openly states that the client has chosen not to meet the agreed period because the workflow is merely “still in progress”. Nor does anyone admit that an extra payment condition has been added because the record is merely “not yet complete”. The software gives delay an impersonal voice and allows the client to replace “we are late” with “it’s on Unifier”, exchanging a statement with an owner for a status that seems to belong to nobody.

The system date is not the contract date

A workflow contains dates because tasks need targets, but an internal target is not the same as a contractual deadline. A contractor may submit on the first of the month, the consultant may have a stated period to assess and the client may then have a further period to pay. Unifier may divide that process into several internal steps, each with its own target date, yet the sum of those steps may exceed the period agreed with the contractor.

Every department can therefore show green while the payment is overdue. Each user may have met the target assigned by the workflow, even though the client has failed to meet the duty stated in the contract. The dashboard reports local task performance and hides the failure of the process as a whole.

The position becomes worse when a record is sent back because one attachment is missing, one code is wrong or one reviewer wants a revised note. The platform creates a new task and a new target, and the original submission date becomes less visible even though it may remain the date which matters. The software has refreshed the task; it has not refreshed the client’s obligation.

A proper payment system would keep the original receipt date fixed, show the contractual deadline, identify the party holding the record and display the time remaining. It would separate an internal service target from the date owed to the contractor and would not allow a clerical return to make an old payment appear new. A green tick is not a certificate, a closed task is not a paid invoice, and a system date is not a contract date merely because it appears in bold.

Configurable, eventually

Unifier is often defended on the basis that it is configurable. That is true in the same way that a building can be moved if enough people, money and machinery are available.

To the system administrator, forms can be changed, routes can be copied, conditions can be added and reports can be built. To the ordinary user, the field is mandatory, the button is grey and the workflow is going nowhere. The distance between those two views is usually a service request.

On many implementations, even a modest change passes through the client’s project team, its information technology department, a system administrator, a service desk and then a distant outsourced support team, often in India. By the time the request reaches the person who can make the change, the reason for it has been reduced to a ticket number and two confused sentences. The location of the support team is not the issue; the service model is. The person who understands Unifier often knows little about the contract, while the person who understands the contract cannot touch Unifier. Between them sits a long chain of people whose main task is to pass the request onwards, so a small amendment to a field, report or route can take what feels like half a century, perhaps arriving before practical completion or, failing that, in time for the final account.

This is the strange meaning of flexibility in enterprise software. Almost anything can be changed, provided the client has enough time, budget, permissions, consultants and patience. For the user who needs the change today, however, the system is rigid at the exact moment when the project requires professional judgement. “Configurable” often means that the software was not fitted to the business before it was imposed on the business.

Designed for people who do not have to use it

Much enterprise software is bought by people who will never complete the common task. Senior managers see portfolio reports, approval control, audit records and the promise of standard processes. They do not see the contractor’s quantity surveyor entering the same amount for the third time, or the supervision consultant searching for the correct action while trying not to send a payment back to the beginning.

The buyer sees the dashboard while the user sees the form, and that difference explains why an old and awkward interface can survive for so long. The people making the purchase often experience the strongest part of the product through summaries, charts and demonstrations in which every user is available, every field is complete and nobody disagrees. The users experience the product on a live project, where staff leave, permissions fail, records are returned, deadlines expire and the previous payment is still open when the next one becomes due.

Project teams also change constantly, so each new contractor, consultant or client employee needs access, permissions, training and an explanation of a process which may be unique to that organisation. Knowledge becomes concentrated in a few administrators, so ordinary users learn by asking the colleague who suffered first and copying whatever worked last month.

Many users do not know why they are completing particular fields because the purpose belongs to an internal client report they will never see. They are told only that the field is mandatory. The result is not better use of technology but ritual data entry, followed by criticism that construction workers are slow to adopt new systems.

Adoption is not achieved by forcing more people to click. A system earns support when it makes a real task faster, clearer or safer, not when it moves the same work into a less familiar screen.

Responsibility travels down while authority stays up

A contractor may be responsible for creating the record but cannot change the workflow. A consultant may be responsible for assessing the amount but cannot release it from the client’s finance route. A programme manager may chase tasks but cannot amend the contract, while the client owns the platform yet points to it as though it were an independent party.

Responsibility therefore travels down the chain while authority remains at the top. Everybody below the client can be accused of failing to use the platform correctly, but nobody at the client is clearly responsible for the full period from valid submission to payment. The workflow divides one duty into many small tasks, each with an owner, while the outcome itself is allowed to have none.

This is why “it’s on Unifier” is such a useful phrase. It replaces a person with a place and sounds more professional than “we have not decided”, while sounding less serious than “we are late”. The record is not being held by a machine but by somebody who has not acted, or by a process designed by somebody who added too many steps, and the software gives that delay somewhere respectable to hide.

A perfect audit trail of a bad process

Unifier can produce a detailed record of actions. It may show when a task was received, opened, returned, approved or sent onwards, and that record can be useful. It cannot, however, prove that the workflow itself was sensible, that the right person made the decision or that the contract date was met.

A needless approval can be perfectly recorded and a weak assessment can have a complete history. A late certificate can contain dozens of timestamps explaining how each department used the available time, yet none of those timestamps makes the delay proper.

Audit teams often respond to a failure by adding another field, reviewer or approval threshold. The new control is visible and comforting, while the future delay is spread across every payment and becomes harder to count. Nobody wants to remove a step because removal looks risky, whereas addition looks careful. The workflow grows until a routine payment begins to require something close to planning permission.

A long audit trail is not proof of good contract administration. Sometimes it is only a very detailed map of the delay. The client may also treat the record on Unifier as the official truth even when the actual commercial work took place in meetings, emails, calls and Excel. The platform is updated afterwards so that the record can move, which means the official system becomes an orderly copy of work carried out somewhere else rather than a single source of truth. What it provides is a single source of status.

The client still pays for it

Late payment first hurts the contractor and its supply chain, but the client does not escape the cost. A contractor required to finance completed work will price that risk through tender rates, finance charges, slower procurement, reduced competition, greater caution from subcontractors or more time spent protecting contractual rights. Smaller firms have less room to carry the client and may simply avoid the work.

The client also pays for the administration itself. It buys licences, implementation services, support, training and custom reports. Contractors add commercial staff to operate the process, consultants seek more resources to review and chase it, and programme managers employ system teams to explain why the system team must be consulted. Everybody then keeps separate Excel registers because the official platform cannot answer the daily question quickly enough.

The client may therefore pay for the software, pay to configure it, pay the project teams to feed it and pay again through the commercial effect of delayed payment. There is rarely a line on the dashboard for the cost of maintaining the dashboard, nor for the professional time lost to correcting metadata, chasing access and moving records through internal routes.

A supervision consultant should be checking quantities, records, changes, programme effects and compliance with the contract. Every hour spent repairing the client’s platform is an hour not spent on the work for which the consultant was appointed. The client has not improved contract administration if it merely replaces part of that work with platform administration.

The wider construction software problem

Unifier is the clearest example of a wider habit in construction technology. The sector keeps buying broad platforms and bending them around work they were not designed to perform simply. At the same time, specialist products are bought by larger software groups and sold back as parts of an end-to-end package covering estimating, take-off, planning, cost control, document management, contracts, finance and asset records.

The sales story is that everything will finally sit in one place. In practice, products created by different teams for different users do not become one system merely because they appear on the same brochure. The links between them still require mapping, exports, imports, custom reports and specialist support, so Excel returns as the place where users repair the gaps.

Tools such as Candy and CostX became valuable because they were shaped around particular construction tasks. Estimators, quantity surveyors and planners accepted their odd screens and old habits because the software understood the work. It did not need to perform every business function; it needed to perform one difficult job well.

When such products become part of a large suite, the business pressure changes. The owner wants common subscriptions, cloud services, shared accounts and a broad sales message. Features valued by experienced users can be neglected because they do not fit the wider product plan, while missing reports, connections or functions return as another module or consulting service. “End to end” often means that the billing reaches every end of the project.

This is why some construction professionals remember older software so fondly: they are not always praising old technology, but the focus of a tool which knew who it was for. The older tool did fewer things, but it knew who it was for and did not ask the whole project team to change its work so that a portfolio dashboard could look tidy.

Construction is not one company

One reason these systems fail is that they assume a construction project behaves like one permanent organisation, when it does not. A project is a temporary group of clients, designers, consultants, contractors, subcontractors, suppliers, authorities and operators, linked by contracts but carrying different duties, records, systems and risks.

The contractor’s payment application is not the client’s internal approval. The consultant’s assessment is not the contractor’s valuation, and the client’s finance check is not the certificate. These records should be connected and traceable, but they should not be collapsed into one owner-controlled workflow which treats every other party as an internal department.

When a client platform forces all parties into its process, external organisations become unpaid branches of the client’s office. Their own systems and records are treated as temporary preparation for the “real” record in the client’s database, even though those systems often contain the detailed commercial information and the client platform contains little more than a summary and an attachment.

The order should be reversed: the client system should receive and connect the proper records created by each party, preserve who created them, record when they were received and show what was assessed, certified and paid. It should not require each organisation to recreate its work inside the client’s preferred form simply to satisfy the client’s internal reporting structure.

Better technology should remove work, not move it

The answer is not to return to paper files, uncontrolled spreadsheets and endless email chains. Construction needs better technology, but it needs technology aimed at the real problem rather than technology which creates another administrative layer.

A useful system should reduce duplicate work by taking data from the tools already used for estimating, measurement, planning, accounting, procurement, site records and document control. It should connect and present that information without asking each organisation to type it again, while preserving the separate record and authority of each party.

It should help the client answer practical questions. What was submitted, what was assessed, what remains disputed, which contract date applies, who must act, how much has reached the bank and where cost, progress and procurement are moving apart. It should also leave construction professionals in control of professional decisions. Software can test arithmetic, compare records, identify missing evidence and flag overdue actions, but it should not decide that an otherwise valid payment ceases to exist because a drop-down list was left blank.

The test is not how many functions the platform contains. The test is whether the common task becomes faster, clearer and less prone to error. Technology should remove typing rather than create more of it, and it should reveal responsibility rather than give delay a safer place to hide.

Why Palantir points in a better direction

This is why platforms such as Palantir are more interesting than another owner portal. The useful idea is not that one product should replace every specialist tool, but that a client can connect data from the systems people already use and create a joined view without forcing every user and every transaction through one giant workflow.

The estimator can continue to estimate in an estimating tool, the planner can use planning software, the contractor can retain its accounting records and the consultant can assess payment in a tool suited to measurement and valuation. The client can then draw the resulting data into its own reporting and checks, while leaving the professional work where it belongs.

That does not make Palantir a magic answer, and the brand matters less than the model. Poor data and poor process do not become good merely because they are connected to a more powerful platform. A client still needs staff who understand construction, contracts and data, and it still needs clear rules about ownership, access and authority.

The better direction is to pull information from the work instead of pushing more administration onto the people doing it. A useful client platform could read the signed assessment, capture the key amounts, compare them with the contract register, match the payment against finance records, flag the contractual deadline and show where action is needed. The contractor submits once, the consultant assesses once, and the client’s technology and staff carry out the client’s remaining work.

That is a far better use of software than asking a quantity surveyor to type a number into a field which already appears in the attached certificate.

The client can keep the dirty work

A client is entitled to choose how it runs its organisation. It may want Unifier, another enterprise platform or several of them, together with detailed coding, portfolio reports, funding controls and a complete internal audit record. What it cannot fairly do is treat the labour needed to maintain that system as a free service from the contractor and consultant.

Where the client wants Unifier, it should employ Unifier administrators, data staff and commercial systems staff at its own end. Those people should create and maintain the records, assign internal codes, upload approved documents, manage permissions, chase client approvers and prepare client reports. They should also sit close enough to the commercial and contract teams to understand what each field and route is doing, rather than receiving stripped-down tickets through several layers of support.

The contractor and consultant may still use a portal to make and receive formal submissions where that method is stated clearly, tested properly and priced into their work. They should not be expected to maintain the client’s internal data model, repair its workflows or carry its reporting burden without payment. Where the platform is introduced after the contract is signed, a new login should not create a new condition of payment, and a failure of the client’s workflow should remain the client’s failure.

The rule should be simple: submit once, assess once and capture once. Any further handling required only for the client’s own reporting belongs at the client end. The client can have any dashboard it is willing to pay for, but it cannot pretend that the data entry is free merely because the work has been pushed out of sight.

The record may be on Unifier. The obligation is still with the Client.

Unifier can be useful when it is designed well, staffed properly and kept in its proper place. It can hold records, route tasks, connect cost data and give a client a broad view of its programme. It becomes harmful when the workflow is allowed to outrank the contract, when users are forced to duplicate work and when the platform gives the client somewhere to hide delay.

The client bought the software, set the process and controls the internal approvals. It should therefore own the administration and the consequences. The next time somebody says that a payment is “on Unifier”, the proper response is to ask who has the task, what decision remains, what date the contract set and why that date has not been met.

A system status is not a contractual answer. The record may be on Unifier, but the obligation remains with the client.