From the contract to the line of code

A contract has milestones. A milestone is delivered by a stream of cards. A card is built from a plan, and the plan cites the decisions it rests on. In onMain the commercial record and the delivery record are one record, so showing a client where their money went is reading the chain, not writing a report.

Two records kept in step by hand

In most shops the contract, its milestones and its invoices live in one tool and the work that delivers them lives in another, and someone keeps the two in step by hand: a milestone re-typed from a plan, a status report written from memory, an invoice raised against a line nobody can trace back to a commit. The two drift, and a client asking where their money went gets a report instead of the record.

One chain, contract to decision

An illustrative project: a signed statement of work, one of its milestones, and the work that delivered it, down to the decision the last card rests on. Each record is joined to the one above it — the portal shows the join, not a figure re-typed into a second tool.

  1. SOW-004Statement of work: checkout rebuildSigned · $48,000 · three milestones

  2. has the milestone

    M2Card payments liveAccepted, approver recorded, 12 Sep

  3. delivered by

    StreamPayments on one providerShared with the client · now: refunds

  4. staged as the card

    Card 212Refunds go through the provider’s APIIn progress

  5. built from

    Plan 31Refunds through the providerExecuting · phase 2 of 3

  6. rests on

    ADR-014One payment provider, not twoAccepted

Example — an illustrative project, not a real client.

Nothing in that chain is written twice. The milestone is the statement of work’s; the stream is the milestone’s work; the card, the plan and the decision are the engine’s own records. The client reads the parts marked for them; the rest stays inside.

What staff record, and what a client’s managers read

Staff record a change request and its approval against the signed contract, and an invoice against the milestone or the approved change it bills. The client’s managers read both: the contract’s current terms beside its signed ones, and each invoice once it is sent. A client’s other people see the milestones and whether each is accepted, without the amounts. Every acceptance and every approval names an approver — and none of it is a client’s to enter.

What onMain does not do

onMain records an invoice against the milestone or the change it bills, and tracks whether it is planned, sent, paid or void. It does not number it, add the tax, send it or collect the money — your accounting tool does that, and onMain keeps the number and the date it returns. And a client writes nothing in the portal: not an acceptance, not an approval. Staff record both, and the client reads the record. The portal is a window onto the work, not a second place to run it.

One record, and it is kept

Because the invoice points at the milestone and the milestone at the stream of cards, a figure on a bill traces to the work that earned it. Every acceptance, approval and invoice is audited and nothing is deleted — a milestone ends accepted or an owner revokes it, a change request is answered by another rather than erased, a void invoice stays on the record. The client reads a history, not a snapshot.

Questions

Does a client approve milestones or change requests in the portal?

No. Staff record an acceptance or an approval, naming an active approver on the project; the client’s people read it. The portal takes no write from a client but an idea they file.

Does onMain send the invoice?

No. onMain records the invoice against the work it bills; your accounting tool numbers it, adds the tax, sends it and collects the payment. onMain keeps the number and marks it sent, then paid — and totals each contract’s invoices against its current value.

What happens to the contract when the scope changes?

A signed contract’s terms are never overwritten. Staff record a change request — a change in scope and in value, with an optional new end date — and its approval; the contract’s current terms are its signed terms plus every approved change, computed, never stored. Billing reads the current terms.