Extracting Payment Terms From a Services Contract

The payment clause in a services agreement usually contains no prices. It says fees shall be as set out in Exhibit A and then describes invoicing, timing, late charges and disputes. The amounts live in an exhibit or a statement of work with its own terms, and the two can disagree.

The clause and the schedule are two documents

Divide the fields by where they live, because the extraction is a join and the join key is the reference in the clause.

• In the clause: invoicing frequency and trigger, payment period, currency, method, late charges, disputed-invoice handling, set-off rights, expenses, taxes, and whether a purchase order number is a condition of payment.
• In the schedule, exhibit or statement of work: the actual fees — rates by role, fixed fees by milestone, subscription tiers, usage rates, minimum commitments — and very often a payment period of its own that differs from the clause’s.

So the clause-level extraction needs an explicit reference field: the identifier of the document referred to as printed, plus a resolution status. Three states, all real. Resolved, meaning you located an exhibit with that identifier in the same file. Unresolved, meaning the clause references Exhibit A and the file you were given contains no Exhibit A — an incomplete document, and a finding. And absent, meaning the clause states the fees inline and there is nothing to join, which is normal on short agreements.

The unresolved case is common enough to build for. Agreements circulate with exhibits detached, executed signature pages arrive separately, and a statement of work signed eight months later is a different PDF entirely. An extraction that returns payment mechanics with no amounts and no explanation reads as a bad extraction; one that returns mechanics plus “Exhibit A referenced, not present in this document” is a correct extraction of an incomplete file.

Net 30 from what

A payment period is a number and an anchor, and the anchor is the part that is dropped. The same “30 days” produces materially different dates depending on which of these the clause says:

• From the invoice date. The default assumption, and the one favourable to the payee.
• From receipt of an undisputed invoice. Receipt is later than issue, and the word undisputed makes the clock conditional — raising a dispute stops it. This is a separate boolean worth extracting.
• From acceptance of the deliverable. Anchored to an event defined in another clause, which may itself have a deemed acceptance period. Two joins deep.
• End of month following. A period counted from the end of the month in which the invoice fell, common in European drafting and expressed in several phrasings that do not contain the word net at all.

Early-payment discount terms appear as a compressed notation — two figures and a net period, meaning a percentage discount if paid within the shorter period, full amount by the longer. It is one token to a reader and three fields to a schema, and a model asked for a payment period from that notation will frequently return the discount window as the term. Detect the notation explicitly and expand it.

Late charges carry their own unit trap: a rate stated per month is not the same as a rate stated per annum, and the difference is a factor of twelve. Extract the rate, the period it applies over, and any qualifier limiting it to the maximum permitted by law — that qualifier is a boolean, not part of the rate.

Amounts, currencies and the doublet check

Contracts give you a free validation that ordinary documents do not: material amounts are written twice, in words and in numerals. If the two disagree, that is a finding — and in practice it is usually the result of a figure being amended in one place and not the other during negotiation, which is exactly the sort of thing worth surfacing.

So parse both. Extract the numeral, extract the words, convert the words to a number, compare, and emit a mismatch flag with both readings rather than silently preferring one. This costs nothing, it catches OCR digit errors on the numeral, and it is the only self-checking arithmetic these documents offer.

Currency needs its own care. A bare currency sign is ambiguous across several currencies that use it, and the disambiguation is usually a definition elsewhere in the agreement rather than anything in the amount itself. Extract the currency as a separate field with a source — stated in the amount, defined in a definitions clause, or inferred — and mark the inferred case. In fee schedules originating in continental Europe the decimal separator is a comma and the thousands separator a full stop, which turns a five-figure fee into a small decimal if parsed with the wrong locale; the reliable test is the position of the last separator relative to the two trailing digits, not the presence of either character.

Fee schedules are tables, so they bring every table failure with them: a merged header cell spanning two rate columns, a second page whose columns shifted, a footnote marker attached to a rate that changes it conditionally, and a total row that a naive parse reads as another line item. Sum the line items and compare to any stated total — when the schedule provides one, the extraction checks itself.

Tax, expenses and the things that change the total

The amount in the schedule is rarely the amount payable, and the modifiers are all in the clause:

• Exclusive or inclusive of tax. Fees stated exclusive of value added tax, sales tax or equivalent means the payer adds it. Inclusive means they do not. One word, and it moves the total by the tax rate.
• Withholding and gross-up. A provision requiring payment to be increased so the payee receives the stated amount net of any deduction. Present or absent; extract as a boolean with its source text.
• Expenses. Reimbursable or not, capped or not, requiring prior approval or not, and subject to a travel policy that is another referenced document.
• Minimum commitments and true-ups. A floor on the amount payable regardless of usage, which makes the effective total independent of the rate table for low volumes.
• Set-off. A right to deduct amounts owed, or an express waiver of it. The waiver is the more common and the easier to miss, because it is phrased as a negative.

Precedence decides which one wins

You now have two payment periods: the master agreement says one thing, the statement of work says another. Both are correctly extracted. The document that resolves them is a third clause, usually in the miscellaneous section, saying that in the event of a conflict the terms of the agreement control, or that the statement of work controls, or that the agreement controls except where the statement of work expressly references the section it is overriding.

That last formulation is the one worth extracting carefully, because it makes precedence conditional on something checkable: does the statement of work expressly reference the section. A pipeline can test for that reference and report the answer. It cannot decide the conflict, and it should not try — the useful output is the conflict itself, stated with both values, both source locations and the precedence rule as printed.

And if there is no precedence clause, say so. That absence is the finding, it is invisible to any field-level check, and it is the reason to run a clause-inventory pass over the whole agreement rather than only extracting the clauses on your list. A contract review that reports which expected provisions are missing is doing something no per-field confidence score can do — the same argument that applies to an agreement with no indemnity and to a termination section with no convenience right.