How a contract system divides work with ERP, CRM and e-signature

Almost every company has run this chain: sales records a closing figure in CRM, legal exchanges six versions of the document with the counterparty over email, an administrator takes the final file to an e-signature platform, and finance keys the amount and payment milestones into ERP. The same handful of fields is entered four times by four people, and a change in any one of them propagates to none of the others.

The problem is not that any of these systems does its own job badly. It is that no system holds the answer to which draft is currently in force. The CRM figure is stuck at the quoting stage, the ERP milestones came from manual entry after signing, the e-signature platform holds only the file that was signed, and the negotiation itself lives in email and chat. When an obligation is disputed and someone needs to reconstruct what happened, no single system can answer on its own.

Adding a contract system is not about adding a fifth place to type things in. It is about giving the version and the decisions one clear home, so the other systems read from it instead of each keeping their own copy.

Once the system of record is settled, field direction has a default answer: customer master data flows from CRM into the contract system, structured results from the executed contract flow out to ERP and finance, and signing is initiated by the contract system, executed by the e-signature platform, and returned. Flows in the opposite direction need a specific reason, or you are simply building a second source of truth.

Zico treats this layer as a standard interface rather than a set of bespoke scripts: ERP, finance and internal control systems connect over standard APIs and webhooks, the signing path connects to e-signature and seal management, and contract data is written back to the systems that need it. Per-use capabilities such as electronic sealing, OCR and business registration checks are listed separately as value-added services on the pricing page rather than bundled into the licence, so usage can be accounted for as it occurs.

Treating e-signature as contract management

This is the most frequent one. An e-signature platform solves identity, intent and evidence at the moment of signing, and by design it only sees the one file that was signed. The rounds of edits during drafting, the comment legal raised and the business overruled, the question of who approved a softer payment term: none of that falls within its remit. Using its archive as a contract register keeps the outcome and discards the process that produced it, and disputes are almost always about the process.

Treating the ERP contract module as the system of record

Contract modules inside ERP usually exist to support orders and payments. They want computable fields such as value, term and milestones, and their handling of the document itself is limited. For a company whose contracts are mostly standard purchase orders with little clause negotiation, that is perfectly adequate. Once inbound third-party papers and multiple redline rounds appear, pushing the document and the negotiation into ERP becomes awkward, legal retreats to email, and what remains in the system is a shell for recording outcomes.

One system per business line

Sales contracts follow CRM, procurement contracts follow ERP, employment contracts follow the HR system. Each choice is defensible on its own, and the combined result is that legal has no view that can answer how many contracts this quarter departed from the standard liability clause. Group structures reach this state especially easily, because each system was introduced in a different year by a different department.

There is no need to start from the org chart. Three observable questions locate the problem: after a contract is executed, how many fields have to be re-entered by hand into another system; when something is disputed, how many places must be opened to reconstruct the history; and can legal see in-flight contracts across every entity and business line in one view.

If two of the three answers are unsatisfactory, the version and the decisions have already scattered and a system of record needs naming. Whether that is a new system or an existing one depends on whether the existing one can carry document versions and clause-level decisions. If it cannot, replacing it immediately is not the only option: pulling out just the review and negotiation stretch, with results returning to the existing flow, is a cheaper opening move.