When existing processes cannot change: upfront fields and external approval chains

The common route for non-litigation contracts runs like this: the business uploads the document, fills a form and submits it for review; once legal has finished, someone re-enters the counterparty, amount, term and payment milestones in the register format. The same information from the same contract is keyed in once at each end of the process.

There is a reason for the duplication. Form fields are written for the business and ask what this deal is for. Register fields are written for legal and finance and ask what this contract looks like on the books. Because the two vocabularies differ, systems tend to park them at opposite ends of the flow and let each side fill its own.

Why asking the business to be more careful does not fix it

Legal and finance sit in the middle of a contract process; the business sits at both ends. Any design that asks the business to type something twice gets routed around during rollout: fields are filled carelessly, or submission is delayed, and legal ends up completing the record anyway. Removing one pass of data entry is therefore not a comfort improvement. It determines how complete and how accurate the register is.

This is also why companies look beyond the contract features built into their collaboration platform. Platform-side forms are generic, and what they cannot change is when a field appears. When a field appears and who confirms it is exactly what this requirement is about.

The workable version has fields appear at upload but not through typing. Once the contract is uploaded, the system extracts the fields the register needs and presents them with confidence scores, so the owner checks and corrects rather than entering from scratch. By the time review starts the register is already populated, and approval follows review without a re-entry step in between.

1. 1The business uploads the contract along with the few things only a person can state.
2. 2The system extracts counterparty, amount, term and payment milestones, each with a confidence score.
3. 3The owner checks each one, corrects what was extracted wrongly, adds what could not be found, and confirms.
4. 4Legal reviews the substance of the contract, with register fields already in place rather than queued as separate work.
5. 5Before submission for approval, the system compares the current draft against the confirmed fields and flags each disagreement.

Extraction itself is an available capability, and bulk loading of legacy contracts uses the same path: results carry confidence scores and can be corrected by hand. The only difference is when it runs, in a batch during migration or on arrival for a new contract.

Capturing fields early removes duplicate entry and introduces a new problem. Review and negotiation produce new versions: the counterparty returns a redraft, the amount settles lower, payment shifts from a single sum to instalments. The fields were confirmed against the first version, and with nothing looking back at them the register keeps the old numbers. That kind of error is quiet, and usually surfaces at reconciliation or when a renewal reminder fires.

The fix is one check before submission for approval: compare the current draft against the previously confirmed fields and list each disagreement, naming the field and what the document now says. The owner can correct the field, or confirm and submit as is, and the system records that confirmation.

Why a prompt rather than a hard block

In contract work, a field disagreeing with the document is not always an error. A framework agreement has no fixed total by design, and an amendment changes one clause while the rest of the master contract stands. In those cases the prompt is noise. A hard block turns the exception into a dead end and pushes owners to find a way around it, and the workaround takes the genuine mismatches with it. A prompt plus a record holds up better: the judgement stays with a person, the evidence stays with the audit trail.

Two questions are worth asking when evaluating this. Does the check happen before or after the contract enters the approval chain, and when someone submits as is, is that choice recorded. The first decides whether a mismatch can be caught in time; the second decides whether a later review can tell who waved it through and when.

Having two or more approval systems inside one group is normal. Anything that spends money goes through an in-house spend-control or budget system; anything that does not goes through the collaboration platform's built-in OA. Each has its own rules and its own history. Most contracts involve money, which puts a new contract system directly on that dividing line.

There are two ways forward. One is to rebuild the spend-control rules as an approval matrix inside the contract system, at the cost of maintaining the same rules twice: every adjustment on the finance side has to be mirrored here, and until it is, the two systems name different approvers for the same contract. The other is to accept that the rules do not belong to the contract system, let spend control return an approval chain based on contract type, department and amount, and merge that chain into the contract system's approval step.

What this route assumes

Identities on both sides have to line up. When the company sits under one collaboration platform directory, an approver returned by the external system resolves to the same person inside the contract system. If each side keeps its own accounts with no mapping between them, the returned chain has nowhere to land, and identity has to be sorted out before approval integration is worth discussing.

The other thing to settle is failure. The external system returns nothing, returns an approver who has left, or returns an empty chain. Each case needs a defined fallback, usually diverting to a chain configured inside the contract system and notifying an administrator, rather than leaving a contract parked with no next step.

Both patterns started as a single customer's requirement: do not make us type fields twice, and do not orchestrate approval here. Neither would rank on a general contract management feature list, yet each decided whether the rollout went live. What matters is how it ends. As a branch of code for that customer, the next similar request starts from zero. As configuration, one rollout becomes a capability of the product.

The test is whether the change can be expressed as configuration. When a field appears, who confirms it and where the consistency check sits are process configuration. Whether an approval chain comes from internal rules or from an external system can be a type of approval step rather than a special case in code. What can be expressed that way should be; what cannot is genuine custom development, billed by person-day.

For buyers, this question separates vendors better than a feature list does. The list items look much alike across vendors, while what shows up during rollout is whatever the list left out.

Both patterns above come from our own rollouts, so the interest is declared: Zico treats requirements of this kind as capabilities to fold into configuration rather than a branch of code kept for one customer. That is our approach, not a judgement on anyone else's, and the question above is worth putting to every vendor.