How to Extract Contract Values and
Compute Running Totals Across Agreements
The procurement director asks a simple question before the board meeting: "What's our current committed spend across all active vendor contracts?" You open the shared drive. There are 47 contracts — some PDFs, some scanned agreements — spread across 14 vendor folders. The answer is scattered across cover pages, fee schedules, amendment letters, and exhibits. Each agreement states its value somewhere. No single document states the total across all of them.
Key Takeaways
- 47 active vendor contracts, one board meeting question — "what's our total committed spend?" — and the answer is scattered across cover pages, fee schedules, amendments, and exhibits no one has time to read.
- Contract values resist aggregation because fees are split across 4+ sections with inconsistent labels, and amendments silently override original numbers — template-based tools can't track which version supersedes which.
- ImageToTable.ai reads every fee component across the entire agreement — including amendments — and sums them into a per-contract total during extraction, so the board's question gets answered in minutes.
The Contract Value Blind Spot
Most organizations know exactly how many contracts they have active. They track expiry dates — or at least try to. Renewal calendars exist, even if they live in someone's Outlook rather than a CLM. But one number is consistently missing from the picture: the running total of what all those agreements are worth.
This blind spot has real consequences. A procurement team that cannot answer "what is our total committed spend" in under five minutes is flying blind on budget planning. A legal department that cannot see the aggregate liability exposure across its vendor portfolio is taking risks it cannot measure. A small law firm managing client matters cannot tell a prospective partner how much recurring revenue sits in its active engagement letters.
The numbers exist — each contract states its value, its fee schedule, its payment terms. The problem is not that the data is missing. The problem is that it is dispersed across dozens of documents in different formats, with values expressed in different structures. A service agreement puts the annual fee on the cover page. An employment contract buries total compensation across a salary clause, a bonus schedule, and a benefits appendix. A vendor agreement splits the contract value across a base fee, a per-unit rate, and an amendment that adjusted both.
A running total across your contract portfolio is not a CLM problem — it is an aggregation problem. You do not need a six-figure contract lifecycle management platform to answer "how much are all our contracts worth." You need a way to get the numbers out of the PDFs and into a structure where they can be summed. That problem breaks into three steps: extract, compute, aggregate.
Why Contract Values Resist Aggregation
Contract values are structurally harder to aggregate than, say, invoice totals. An invoice has a single "Total" field in a predictable location. A contract can distribute its financial obligation across multiple sections with inconsistent labels.
Consider what happens inside a typical vendor agreement:
- Section 3.1 states the annual license fee as "$48,000 per year, payable quarterly."
- Schedule A lists three optional add-on services at $2,400, $1,800, and $3,600 per year.
- Amendment #2 adjusts the license fee to $52,000 starting Year 2.
- Exhibit C specifies a one-time implementation fee of $7,500.
A person reading this contract can add these up — but it takes time, and the numbers are in four different places. A traditional OCR tool fares worse: it might find the license fee but miss the add-ons, or extract the old rate from the original agreement instead of the amended rate from the amendment letter. And even if it captures everything, you are still left with raw numbers that need to be summed — either by you, in Excel, manually.
This is where the extract-compute-aggregate workflow changes the equation. The extraction step uses AI that reads for meaning — not template matching — so it finds values regardless of where they sit in the document. The computation step sums line items during extraction, so the output already contains the per-contract total. The aggregation step takes the output spreadsheet and adds running totals and portfolio percentages — formulas that work the same way whether you have 5 contracts or 500.
Step 1: Extract Individual Contract Values
The first step is getting the numbers out of each contract and into a structured table. This is where contract field extraction does the heavy lifting.
With ImageToTable.ai's Custom Column Extraction, you define the fields you want by typing their names — no templates, no bounding boxes, no training on sample documents. The AI locates each value by understanding what the field means semantically, regardless of where it appears in the document or how it is labeled. A value described as "Total Consideration" in one contract and "Contract Price" in another maps to the same output column because the AI understands both labels refer to the same concept.
For a contract portfolio overview, you would typically define columns like:
Upload all 47 contracts as a batch — drag and drop works with PDFs, scans, and even phone photos of signed agreement pages. The AI processes each document independently, locating and extracting the specified fields. The result is a single spreadsheet where each row is a contract and each column is a field you defined.
This already gives you more than you had before: a structured table with counterparty names, dates, and fee components — all extracted in 5-10 seconds per document, versus the minutes per contract it would take to read and transcribe by hand. But the output so far is raw values. To get a per-contract total, you need computation during extraction — and that is where computed columns come in.
Step 2: Compute Per-Contract Totals During Extraction
A raw extraction gives you "Base Fee: $48,000" in one column, "Add-on Fee: $2,400" in another, "Amendment Adjustment: +$4,000" in a third. Useful, but not yet actionable. What you actually need is one number per contract: the total committed spend.
This is what computed columns solve. Instead of extracting raw values and summing them later in Excel, you instruct the AI to perform the summation during extraction. The output already contains the total — no post-processing required for the per-contract figure.
Add a computed column to your column list that sums all fee components within the same contract:
Column name (no login required)
Rule Format (login required, cleaner column headers)
Because the AI reads the entire document and understands its structure, it can identify which fee components belong to the same contract and aggregate only those — even when fees are spread across the main body, schedules, and amendments. This is fundamentally different from a spreadsheet formula that references fixed cell positions. The AI does not need to know that "Base Fee is in column F and Add-on Fee is in column H." It reads the document, understands what each fee represents, and sums them.
Files are processed securely and not stored. Try adding a computed column like Total Contract Value (sum of all fees in this agreement).
When you need multi-step reasoning — such as distinguishing between the original fee in the main body and the amended fee in an amendment letter, and using the amended value — enable Precision+. This toggle gives the AI additional reasoning steps to cross-check relationships, verify which version of a fee should apply, and confirm internal consistency before outputting results. For straightforward contracts where all fees are in one place, leave it off. For amended agreements with fee schedules spread across exhibits, turn it on.
At this point, your output spreadsheet has a "Total Contract Value" column with one number per contract. Every contract in the batch has been read, its fees identified and summed. You have answered "how much is each contract worth." Now you need to answer "how much are all of them worth, together."
Step 3: Build Running Totals and Portfolio Percentages
The aggregation step happens in the output spreadsheet — and it is the simplest part of the workflow because the extraction and computation steps have already done the hard work.
Computed columns operate within a single document: they can sum fees inside one contract, but they cannot reference values from other contracts in the batch. That cross-document aggregation is what the spreadsheet handles. And because each contract already has a clean "Total Contract Value" in its row, the formulas are trivial.
Open the downloaded Excel file. Your columns look something like:
| Counterparty | Contract Title | Effective Date | Expiry Date | Total Contract Value | Running Total | % of Portfolio |
|---|---|---|---|---|---|---|
| Acme Corp | SaaS License Agreement | 2025-01-15 | 2027-01-14 | $55,800.00 | $55,800.00 | 21.4% |
| Beta Industries | Master Services Agreement | 2025-03-01 | 2028-02-28 | $142,500.00 | $198,300.00 | 54.6% |
| Gamma Logistics | Distribution Agreement | 2025-06-01 | 2026-05-31 | $62,400.00 | $260,700.00 | 23.9% |
Two formulas produce this view:
Running Total — cumulative sum down the column:
Drag this down and each row shows the total value of all contracts up to that point. The last row gives you the portfolio total — in this case, $260,700.
% of Portfolio — each contract's share of the total:
This tells you, at a glance, that Beta Industries represents over half of total committed spend — a concentration risk worth knowing about.
These formulas are two of the simplest in Excel. The value of this workflow is not in formula complexity — it is that the numbers feeding into the formulas arrived in the spreadsheet without anyone having to read 47 contracts and type values by hand. The extraction and computation steps eliminated the bottleneck. The aggregation step is the easy part.
When This Workflow Replaces a CLM — and When It Doesn't
Contract Lifecycle Management platforms — Ironclad, Agiloft, Icertis, Juro — are purpose-built for enterprise contract operations. They handle approval workflows, clause libraries, obligation tracking, e-signatures, and compliance reporting. If your organization needs those capabilities, a CLM is the right investment.
But many teams do not need the full CLM feature set. They need something narrower: the ability to answer specific questions about their contract portfolio without reading every document. Questions like "what is our total exposure across these vendor agreements" or "which contracts account for more than 20% of our committed spend."
The extract-compute-aggregate workflow fits that narrower need. Here is when it works and when it does not:
| Scenario | Extract + Compute + Aggregate | Full CLM |
|---|---|---|
| Need a one-time portfolio value overview for a board meeting | Ideal fit | Overkill — months of implementation for a one-time need |
| Quarterly spend analysis across 50-200 vendor contracts | Well suited | Viable but the per-seat cost may not justify the frequency of use |
| Need clause-level obligation tracking with automated alerts | Not designed for this | What CLMs are built for |
| Multi-stakeholder approval workflows on contract drafts | Not relevant | Core CLM function |
| Small firm managing 30 client engagement letters — need recurring revenue overview | Ideal fit | Price-prohibitive for the scale |
The boundary is clear: if your primary need is knowing what is in your contracts — values, dates, counterparties — the extraction workflow gets you there. If your primary need is managing the contract as a living process — negotiations, approvals, renewals — a CLM is the right tool. Many teams will use both: the extraction workflow for periodic portfolio snapshots, the CLM for ongoing contract operations.