Contract ledger template: which fields you need and how to pull them from the contract text

1. Contract identity

• Contract number: generated by one rule, one number per contract, with amendments linked to the main contract.
• Contract name: use the title in the document rather than inventing a new one.
• Contract type: purchase, sales, services, lease, framework agreement and so on. The type decides which approval path and which review checklist apply.

2. Parties

• Your signing entity: list it separately when the group has several legal entities, or the ledger cannot tell which company signed.
• Counterparty: full legal name.
• Owning department and contract owner: who to ask when something goes wrong.

3. Amount and payment

• Total amount, currency, and whether tax is included.
• Direction: receivable or payable.
• Payment milestones: by percentage or by deliverable, with the condition and date of each. A framework agreement without a total should say "settled per order" rather than carry an invented figure.

4. Term and obligations

• Effective date, end date, and whether it renews automatically.
• Key milestones: delivery, acceptance, end of warranty.
• Reminder lead time: how many days before expiry, and who is notified.

5. Status and filing

• Current status: drafting, in approval, signed, in performance, terminated.
• Signing date and method (wet ink or e-signature).
• Where the original or the signed scan is stored.

Define every field. Is "amount" before or after tax? Is "expiry" the end date or the last payment milestone? Without a definition, different people will enter different numbers.

Say who fills each field, and when. Number and type are set when the contract is created; amount and payment milestones follow the final agreed version; signing date and filing location are added after signature.

Do not add every optional field at once. More fields mean more gaps. Run the required fields for three months, then add fields for the questions people keep asking.

The most laborious part of building a ledger is usually the back catalogue: hundreds or thousands of Word files, PDFs and scans. Typing them in one by one is slow and error-prone.

A safer approach is extract, then confirm:

1. 1Fix the field definitions first and write them down.
2. 2Extract candidate values such as parties, subject matter, amount, term and payment milestones from the contract text, with missing fields listed separately.
3. 3Have a person confirm them, especially amount, term and payment milestones, which feed reconciliation and expiry reminders directly.
4. 4Write them into the ledger and spot-check a sample against the originals.

Two cautions: extracted values are candidates, not final values, so do not approve them all by default; and the signed scan should be checked against the final draft so the ledger matches the version that actually took effect.

A spreadsheet ledger lives apart from the contract itself. When the text changes, the ledger does not; when a contract expires, nobody is reminded.

In Zico, a contract lifecycle management system from FIM, the ledger is tied to the contract workflow. Contracts started from templates write field values back into the document so the text and the ledger stay consistent; after signature, payment, delivery and expiry milestones feed into reminders; the ledger is searchable, and signed scans can be compared with the final draft. For existing contracts, Zico AI's information extraction can pull fields in bulk, with a confidence level for each field, low-confidence fields flagged for review, and every value traceable to the source text. Teams that already have a contract system or ledger can connect Zico AI alone and send the extracted fields back to their existing ledger.

The Zico contract system is deployed privately and quoted per client.