Extracting Delivery and Acceptance Criteria From a Purchase Contract

“The Deliverable shall be deemed accepted if the Customer does not provide written notice of rejection within thirty days.” The field a buyer needs from that sentence is a date, and the sentence does not contain one.

Deemed acceptance is the reason to bother

Acceptance matters because things hang off it: payment falls due, risk passes, a warranty period starts, and the right to reject the deliverable ends. A clause that makes acceptance happen automatically after a review period means all of those can occur without anybody at the buyer doing anything or noticing. That is exactly why it is worth extracting at scale — not to know what the clause says, but to generate a diary of dates by which somebody has to have looked at something.

The consequence for the schema is that the extraction is only half of the deliverable. The output has to be computable into a date given a delivery event, which means every input to that computation needs its own field, and the fields have to be honest about what they do not know. The most useful thing this pipeline emits is not acceptance_period: "30 days" but a small object that a date library can evaluate once a delivery date exists.

The fields the clause actually has

• The review period — a number, a unit, and critically whether the unit is calendar days, business days or working days, which are not always the same thing across jurisdictions.
• The start trigger. Delivery, receipt, installation, the supplier’s notice of completion, or availability for testing. These occur on different days and the clause picks one.
• The acceptance test. Conformity with specifications, passing an agreed test plan, or the buyer’s reasonable satisfaction — a materially weaker or stronger standard depending on which.
• The rejection procedure. Written notice, with or without a requirement to state the failures in reasonable detail. A requirement to specify defects makes a bare rejection ineffective.
• Cure and re-test. A period for the supplier to fix and resubmit, and then — the part usually left implicit — whether the review clock restarts in full on resubmission. If it does, the deemed-acceptance date is a function of a loop, not of one addition.
• The failure limit. “If the Deliverable fails acceptance testing three times, the Customer may terminate and recover fees paid” — a counter with a consequence.
• Partial acceptance and use-as-acceptance. Whether putting the deliverable into productive use constitutes acceptance regardless of the clock, which quietly overrides everything above.

Reading the clock correctly

Three ambiguities move the answer, on top of the ordinary hazards covered by the date field validation rule, and none of them can be resolved by reading the clause harder.

Inclusive or exclusive of the trigger day. “within thirty days of delivery” conventionally excludes the day of delivery in many drafting traditions, but a contract that says “from and including the date of delivery” means something else, and one that says neither leaves you a choice to record rather than a fact to extract. Store an explicit day_count_convention with a value like exclusive_of_trigger_assumed so the assumption is visible.

Business days need a calendar. A business-day count requires a jurisdiction and a holiday list. The contract may specify one (“days on which banks are open for general business in London”) or may not, in which case the governing-law clause is the best available proxy and should be recorded as the source of the calendar. A supplier in one country and a buyer in another can compute two different deemed-acceptance dates from the same clause, honestly.

The end of the period may not be a business day. Many contracts add that if a deadline falls on a non-business day it rolls to the next one. That rule is often in the interpretation clause at the front of the agreement rather than in the acceptance clause, so an extraction scoped to one clause misses it entirely.

A worked acceptance date

Assume a clause reading “the Customer shall have thirty (30) days from Delivery to notify the Supplier of any failure to conform to the Specifications, failing which the Deliverable shall be deemed accepted”, and a delivery date of Wednesday 2026-03-04. All inputs below are assumptions, chosen to show how the answer moves.

trigger date        2026-03-04 (delivery)
convention          exclusive of trigger day

A. 30 calendar days
   2026-03-04 + 30 days              = 2026-04-03 (Friday)
   deemed acceptance                 = 2026-04-03

B. 30 business days, Mon-Fri, no holidays
   30 working days after 2026-03-04  = 2026-04-15 (Wednesday)

C. as B, with two public holidays inside the window
   30 working days, 2 skipped        = 2026-04-17 (Friday)

D. as A, but inclusive of the delivery day
   2026-03-04 + 29 days              = 2026-04-02 (Thursday)

Two weeks separate A from C, on one clause and one delivery date. That spread is the argument for storing the convention, the calendar source and the unit as fields rather than resolving them silently at extraction time: when the holiday calendar is corrected, every derived date recomputes, and when it was baked into a stored date, nothing does.

Emit the computed date with its inputs attached, in the same spirit as the derived-value discipline on a policy limit stated only as a percentage: a derived field that does not carry its derivation is indistinguish- able from one that was read off the page, and only one of those can be audited.

Criteria incorporated by reference

The acceptance criteria themselves are usually not in the contract. The clause says the deliverable must conform to “the Specifications set out in Exhibit B” or to a test plan to be agreed, and the correct extraction is a pointer, not a null and certainly not a hallucinated list of criteria.

Model it as a typed reference: the target name as written, its type (exhibit, schedule, statement of work, external standard, to-be-agreed), and a resolution status. Three cases behave differently downstream. The exhibit exists in the same PDF, and the reference resolves — follow it and extract the criteria as a separate linked record. The exhibit exists as a separate file, and resolution is a corpus join. Or the criteria are to be agreed later and do not exist yet, which is a genuine contractual gap and one of the more useful things a review can surface: a deemed-acceptance clock running against criteria nobody ever agreed.

The same pattern shows up in almost every clause type in this cluster — a data processing addendum whose subprocessor list lives in an exhibit has exactly this shape — and it is worth having one reference type in the schema that all of them use rather than inventing a different shape per clause.