From won bid to signed contract: check every promise against the annexes

The award letter is not the finish line. Before anyone signs, one question is worth an afternoon: does the contract say what you promised, no more and no less?

Your offer made promises in many places. Service levels in the solution description. Staffing in the organisation section. Milestones in the plan. Payment and indexation in the price assumptions. The contract package arrives as something else: a main contract and a set of annexes, often built from the buyer's draft contract and completed with parts of your offer.

Small gaps between the two are easy to miss and expensive to live with. An annex taken from an older tender package. A clarification answer that never reached the contract. An offer section copied in by hand. Nobody has to act in bad faith for the contract and the offer to drift apart.

Here is a method for checking it before signing, and where Atlas compares the offer with the contract package. The example is made up. The tender, the section numbers and the figures are synthetic, so nothing in it belongs to a real buyer or bidder.

The setup: the contract package lands

An IT services framework. The bid is won. The offer contains seven concrete promises the delivery team will be held to. The contract package has a main contract and four annexes: service levels, timeline, price and payment, and the supplier's solution, taken from the offer.

The signing date is in ten days.

Step 1: turn the offer into a list of promises

Do not start from the contract. Start from what you said.

Go through the offer and pull out every commitment that someone could later hold you to. For each one, write down what, who, when and how it is measured, and the offer section it comes from. "We will provide a named service manager at 0.5 FTE" is a promise. "We are a trusted partner" is not.

In the example this gives seven promises. The list is the backbone of everything that follows, so the bid manager owns it.

Step 2: cross-table each promise against the contract

Now find each promise in the contract package. Atlas compares the offer with the contract package. The table below is the bid team's own working paper, not Atlas output: the bid manager fills it in and checks each line against the list from step 1. Check the main contract, the service level annex, the timeline and the payment terms, not only the annex that copies your offer. A promise can be correct in the solution annex and contradicted two annexes later.

Two of seven match. The other five are what the signing meeting is for.

Step 3: sort the findings into four kinds

Each kind of finding needs a different conversation, so sort before you discuss.

The contract asks more than you offered. Go-live in 8 weeks, not 12. A monthly report, not a quarterly one. These cost money and staff. Delivery has to say whether they are possible at the offered price.

A promise is missing. The named service manager is in the offer and nowhere in the contract. That can look like good news. It is not always. The delivery team plans from the contract, and the buyer remembers the offer.

Two documents disagree. The main contract says 30 days to pay, the payment annex says 45. Someone will read the other one when it matters.

The wording drifted. EU became EEA. Close is not the same. A small change in a data clause can change which hosting setup is acceptable.

Step 4: people decide

The table is a working paper, not a decision. Every finding gets an owner.

The bid manager prepares the table and presents it. The delivery lead confirms what can actually be delivered: 8 weeks to go-live, a monthly report, the named manager. The legal owner approves the contract, and decides what to raise with the buyer before signing.

Some calls never belong to a tool. Which document prevails when two disagree is set by the contract's order of precedence clause, and reading it is a legal call. What can still be corrected at this stage is set by any procurement rules and the tender, and that is also for the legal owner.

Step 5: hand the table to delivery

Once the findings are decided, the table changes job. It becomes the delivery team's starting list: what was promised, where it now sits in the contract, and what was agreed about each gap.

This is where the method stops. It is a consistency check at signing. Tracking obligations through the life of the contract is a different job, with a different owner.

What Atlas does, and what it does not

In this workflow, Atlas compares the offer with the contract package. That takes on the slow part of step 2: reading a long offer and a main contract with several annexes side by side.

It does not give legal advice, decide which document prevails, or approve the contract. The list of promises, the table and every decision stay with the bid team and the owners in step 4.

Two checks stay with the bid team. Read the order of precedence clause before discussing any conflict. And before signing, read scanned pages, signed annexes and tables in images yourself.

How to know it works

We have not measured this, so here are the two measures we would use.

• The number of unresolved conflicting obligations at legal review.
• The share of offer promises that have a contract location in the table at signing.

If the first goes down and the second goes up, the method is working.

Where this sits

The offer to contract check is element 51 (OCC) in our periodic table of commercial work, in the Contract family. Two related elements: amendment handling (AIL) deals with changes before you submit, and the variation draft (VDR) deals with changes after you sign. Each element follows the same shape: one input, one agent task, one human gate, one measure.

The full table, with every element, is at /periodic-table.