Catching the Contract Change Nobody Told Finance About

The revenue errors worth worrying about in a service company are not wrong answers. They are absent questions.

When a genuinely difficult treatment question arises, it gets escalated, because it looks difficult. Somebody senior is involved, the accountant who reports on the statements is often consulted, and the conclusion gets written down. That process works. The errors that actually reach the financial statements come from the other direction entirely: a change to a contract that looked completely routine to the person who agreed to it, was never described as an amendment by anyone, and simply never arrived in front of finance at all.

So the control that matters is not technical. It is a capture control, and its measure of success is completeness rather than correctness. This piece is that control: where changes originate, how finance hears about them without relying on anyone remembering to say, what happens on receipt, and the monthly test that proves the capture is working rather than assuming it.

Almost nobody says the words “change order”

This is the practical difficulty and it is why a rule instructing people to notify finance of contract amendments does very little.

An account manager who agrees on a call to add a second location for a customer has not, in their own mind, amended a contract. They have looked after a customer. A project manager who agrees to absorb a fortnight of extra scope to keep a delivery on track has made a delivery decision. A support lead who extends a trial has made a customer service decision. Each of them would answer no, honestly, if asked whether they had amended a contract that month.

The channels, and what each one looks like at the moment it happens:

Where the change originates	What it looks like to the person making it	Why finance misses it
A call or a meeting with the customer	Good account management	There is no artefact at all unless somebody makes one
An email agreeing to a scope addition	Answering a question	It lives in one inbox and is never forwarded
A ticket or a task added in the delivery system	Ordinary work	Delivery systems are not connected to the contract file
A renewal accepted on different terms	Retaining the customer	The renewal is filed as a renewal, and the change inside it is not flagged
A price change agreed to keep a customer	A commercial concession	Frequently deliberately quiet, because it is a concession
A pause or suspension at the customer’s request	A courtesy	Nothing is billed, so nothing prompts anyone to look
An extension of a term to match a customer’s timeline	Housekeeping	Changes the release period, which nobody outside finance thinks about
A statement of work signed under a master agreement	Normal operating procedure	Often signed by a delivery lead with no copy sent anywhere central
Work started before paperwork is finished	Getting on with it	The most common of all, and the hardest to see

The last row is worth pausing on. Work begun before a contract or an amendment is signed is not a capture failure yet, but it becomes one, because the eventual paperwork is dated later than the work and the revenue period nobody questioned has already closed.

Do not build a rule that depends on remembering

Every company that has this problem has already tried the obvious fix. A message goes out asking everyone to copy finance on contract changes. It works for six weeks. It then decays, and it decays fastest among the people who make the most changes, because they are the busiest.

The design that holds attaches the notification to something the person already wants. Nobody remembers to inform finance. Everybody remembers to get their customer billed, their project resourced and their new user provisioned.

So put the capture form where those requests already go.

Hard gate	What cannot happen without it	What the gate captures
The billing request	The customer is not invoiced for the addition	Value, effective date, and what changed
Provisioning or access	The new users or the new site do not go live	Scope and start date
Project setup or resourcing	The delivery team is not assigned	Scope, term and the delivery owner
The signature process	Nothing is signed without a copy landing in the contract repository	The document itself

Four gates, and the same short form behind each one. A person requesting any of the four answers the same questions once, and finance receives a change record whether or not the requester ever thought of what they did as a contract change. That is the entire trick, and it is the difference between a control that works in month nine and a memo that worked in month one.

The gate that repays the most effort is the signature process, because it is the only one that captures a change carrying no immediate money. A term extension agreed at no additional charge produces no billing request and no provisioning request, and it moves the release period on the schedule.

The intake checklist

This is the executable part. Run it on receipt of any change record, and it takes minutes for a routine one.

1. Confirm the change is against a contract that exists in the schedule. If it is not, you have found a missing original contract rather than an amendment, and that is the bigger problem. Stop and fix that first.
2. Get the document. The signed amendment, the countersigned statement of work, or the email exchange in which the customer agreed. An email thread is evidence. A verbal account of an email thread is not.
3. Record the effective date, separately from the date the document was signed. These differ constantly and the effective date drives everything downstream. Where a change was agreed verbally and papered later, record both dates and note the gap.
4. Write down what actually changed, in one sentence, in plain language. Value, scope, term, price, billing frequency, or a right the customer now has that they did not have before. Somebody reading it in a year should not need the document to understand it.
5. Check whether the change touches a refund, cancellation or renewal right. These are the terms that decide what happens at the end and they are the terms nobody re-reads.
6. Classify the change against the patterns in the policy. If it fits an existing pattern, apply it. If it does not fit, stop.
7. Where it does not fit, escalate rather than decide. Which is the next section, and it is the one rule in this piece that is not negotiable.
8. Update the schedule, with the change and its effective date visible in the contract’s history. The mechanics of that update are the deferred revenue schedule, which is built so that an amendment closes one basis and opens another rather than quietly overwriting a formula.
9. Confirm the billing arrangement moved with the change. An amendment that updates the schedule and not the invoicing set-up produces a correct revenue figure and a wrong invoice, and the customer will find that before you do.
10. Log it in the change register for the period, with the date received, the effective date, and the date the schedule was updated. That register is the input to the completeness test below.

Step 3 does more work than it looks. The gap between when a change took effect and when it was papered is the single most useful number this control produces. A company where that gap is consistently short has a capture process. A company where it is long, or where the two dates are always identical because nobody records the real one, does not yet know what it has.

Step 7, stated plainly

When a change does not fit a documented pattern, the person performing intake does not decide how it is treated. They record the facts, flag it, and it goes to the accountant who reports on the company’s financial statements.

That is not a formality and it is not modesty. The treatment of a contract modification can turn on facts that are not visible in the amendment itself, and it is the sort of question where a reasonable answer arrived at independently is worse than no answer, because a reasonable answer gets applied consistently for two years before anybody re-examines it.

The framework questions in general belong there too. Nothing in this piece tells you how a modification, a scope reduction, a bundled addition or a renewal at a different price should be accounted for. What this piece guarantees is that the question reaches somebody who can answer it, in the month it arises, with the facts attached. Where the answers get written down once so they stop being re-asked is covered in the revenue recognition policy piece.

The monthly completeness check

Everything above is a process, and a process cannot prove itself. The completeness check is the part that turns “we have a capture control” into “we know the capture control caught everything last month”, and it is the step that gets skipped.

The method is a reconciliation of independent populations against the schedule. Independent is the operative word. Comparing the change register to the schedule proves only that finance wrote down what finance received.

Run these five, monthly, in this order.

1. Signature log to schedule. Every document executed in the period, from the signature tool’s own log rather than from the folder somebody maintains. Each one either exists in the schedule or has a written reason why it does not. This is the strongest of the five because the log is produced by a system nobody edits.
2. New customers in the invoicing system to schedule. Any customer invoiced this period for the first time. A first invoice with no contract in the schedule is either a missing contract or an invoice that should not have been raised.
3. New projects or engagements in the delivery system to schedule. Work being resourced against a contract that does not exist in the schedule is the earliest available warning, because delivery usually starts before billing.
4. Closed opportunities to schedule. Anything the sales system recorded as won in the period. This one produces the most false positives and it is still worth running, because the false positives are themselves informative: an opportunity marked won with no contract behind it is a forecasting problem for somebody else.
5. Billing changes to change records. Any customer whose invoiced amount changed from the prior period without a change record explaining it. This is the test that catches amendments made by people who never touched a gate, because eventually the billing has to move and the movement is visible.

Test 5 is the backstop and it is the one to build if you only build one. It requires no cooperation from anybody outside finance, it runs off data finance already has, and it finds the change that evaded every other control, because a change that never affects billing is usually a change that does not affect much.

What you do with an exception

Every exception gets recorded with three things: what was found, how it was found, and how late it was.

The last one is the point. A company that resolves its exceptions and never records when they were found learns nothing, because the exceptions look the same whether they were caught in the same month or discovered in the following year. Recording the lag turns a list of one-off corrections into a measure of the control, and it usually shows that one channel from the table at the top is responsible for most of the lag.

Fix the channel. A change repeatedly arriving late from the same route is a design problem in that route, and it will not be fixed by asking the people who use it to try harder.

Where this sits in the month

Intake is continuous. It happens on receipt, not at close, and a change record waiting for month end is a change record that will be worked at the busiest moment of the cycle by somebody who wants to be doing something else.

The completeness check belongs in the close, before the revenue tie rather than after it, for the obvious reason that its whole purpose is to find things the tie will not. Its place in the sequence, and who signs it off, sit in the close we run as a step with a named owner rather than as a good intention.

What we do not do

We do not accept a verbal account of an amendment, because a change with no document is a change with two versions, one of which belongs to the customer. We do not update a schedule from a billing request alone, since the billing request tells you what somebody wants invoiced rather than what was agreed. We do not decide the treatment of an amendment that falls outside the policy. And we do not run a capture control without the completeness check behind it, because a control nobody has tested is a belief, and this particular belief is usually wrong by more than anyone expects the first time it is measured.