Money before material, and how to sign for it honestly

A great deal of construction purchasing requires money to move before anything arrives. Suppliers of commodity materials often will not dispatch against credit. Fabricated items require a deposit. Concrete plants take payment before a truck rolls.

This is not a bad practice to be eliminated. It is the market. The problem is not that money goes first — it is that the record of a payment usually does not say whether it went first, and by the time anybody asks, the two cases look identical.

For a developer it compounds, because money leaves on the contractor's ladder before it arrives on the buyer's — two payment ladders that never line up.

The two payments that look the same#

Payment A: material was delivered, checked and received; the invoice was matched; the money went out afterwards.

Payment B: money went out so that material would be dispatched; nothing has arrived yet.

On a bank statement these are the same event. In most purchase ledgers they are the same event. And the difference between them is the entire risk position of the company: in the first case you have the goods, in the second you have a promise.

An organisation that cannot separate these cannot answer the only question that matters in a bad week — how much have we paid for material we do not yet have?

Asking at the moment of signature#

The moment to establish this is when somebody is authorising the payment, because that is the only moment when a person is looking at it who knows the answer.

In our own approvals queue, every payment awaiting signature now says one of two things: that delivery documents have been filed against it, or, in amber, that none have — no delivery challan yet — money before material?

It is a question, not a block. That distinction was deliberate and it is the part worth copying. A hard rule refusing payment without a delivery record would be wrong on a large fraction of legitimate purchases, and a rule that is wrong that often teaches people to find the override. Once the override is routine you have neither a rule nor a question.

What the question does is make the signer aware that they are making a choice rather than having one made for them. Some payments rightly precede material. The person signing is entitled to know which kind this is.

Why the question was harder to build than it looks#

The obvious implementation is to ask whether any delivery document is attached to this order. Ours did that, and for a long time it was structurally incapable of ever saying yes.

The document matcher only offered a delivery record against purchases that had not been paid. But in our process payment usually precedes dispatch. So by the time material arrived and somebody photographed the slip, the correct purchase was always in the paid state and was therefore never a candidate. The document matched nothing, and a document matched to nothing appears on no screen at all.

Every payment showed no delivery challan yet, permanently, including the ones where material had arrived weeks earlier and been photographed properly. An amber warning that is always on is not a warning. It is wallpaper, and within a fortnight nobody sees it.

The fix was one sentence: paid purchases are offered the match too, closed ones still are not — a closed order being the real test of a finished purchase. The general lesson is more useful than the fix. A check that cannot ever pass is worse than no check, because it consumes the attention a real warning would have needed.

What has to be recorded#

Four fields turn a payment into something you can reason about later.

Its type. Advance against order, payment on delivery, stage payment, retention release, mobilisation advance. These have different futures and different recovery mechanics — the difference between the last two is set out in a mobilisation advance is not an advance payment.

What it is against. An order, a contract, a stage. A payment attached only to a vendor name cannot be reconciled against anything.

Whether material has been received against it, as a fact that updates when material arrives, not a checkbox somebody ticks at payment time.

What was expected in return, and by when. Without this, an advance that is never fulfilled simply ages quietly. With it, the gap between the payment and the expected delivery becomes a date that can be chased.

The exposure report nobody has#

Given those four fields, one report becomes possible, and it is the point of the whole exercise:

Money paid, against material not yet received, by vendor, by age.

Almost nobody can produce this. It is the clearest statement of counterparty exposure a construction business has, and it is usually reconstructible only by a person going through orders one at a time.

Ageing matters as much as the total. An advance a week old is normal trading. The same advance six months old, to a vendor who has gone quiet, is a different kind of number, and it is exactly the kind that surfaces at year end when somebody asks why an order is still open.

Advances and the signature that follows them#

There is a sequencing trap worth naming.

If money goes out before the order is fully approved — because a supplier demanded payment to hold a rate, because somebody was on site and made a decision — then the approval that follows is a formality applied to a fact. Everybody involved knows the signature cannot change anything.

That situation should be recorded as what it is: money that moved without a prior sign-off, in its own list, where the question is who authorised this rather than shall we. Putting it into the ordinary approvals queue is worse than useless — it fills the queue with decisions that cannot be made and trains signers to click through. The argument about keeping an approvals queue about live decisions is in why one person should never move the company's money.

The short version#

Paying before delivery is ordinary in construction. Failing to record which payments those were is not.

Mark the type at payment, attach it to an order, let the delivery record update the position when material actually arrives, and put the question in front of the person signing — as a question, because a block would be wrong too often to survive.

Then you can answer the one question a purchase ledger is really for: what have we paid for that we do not yet have. The mechanics of matching an arriving delivery back to the payment it belongs to are in three-way matching.