Contract as data: watch

A contract is fields

1. A new contract, invoice or power of attorney is rarely written from scratch: you take the previous document, save a copy and replace the names, amounts and dates in it. Somewhere an old amount stays behind, and the total in figures stops matching the total in words. These errors share one cause: the document's data is mixed in with its text. A supply contract shows how to separate the two and which errors disappear once you do.

2. In a supply contract of several pages, little changes from deal to deal: the party's name, its code, the quantity, the price, the date, the term and the bank account. These are data, the values that describe this particular deal. The rest is text: the wording of clauses that a lawyer agreed once and that moves from contract to contract unchanged. On the page you cannot tell one from the other, because both are printed the same way.

3. To separate data from text, each value is moved into a field of its own. A field is a named cell for one value: the name “price per tonne” and the value itself, 12,400.00. By its name the value can be found and inserted without rereading the text. It is stored in one place, so the party's name, which appears both at the top of the contract and by the signature, is corrected once, and the pages never disagree.

4. Each field also has a type, a mark that says what it holds: text, a number, money or a date. From the type the program knows what can be done with the value: numbers can be multiplied, days can be added to a date. It also knows what the field cannot hold, so it rejects 31 April or a seven-digit code as soon as they are entered. In running text only a careful reader would notice such an error.

5. Where the values were taken out, the text keeps blanks, each labeled with the name of its field. Fixed text with named blanks is called a template. It means the wording is not retyped or edited every time: it is agreed once, and after that nobody touches it. So replacing the price can no longer accidentally delete a word in the liability clause, and nothing from the previous contract stays in the new one.

6. Fields differ too, and what sets them apart is where the value comes from. A person enters a variable field for each deal: the party, the price, the term. Nobody enters a derived field: it is computed from other fields, like the sum or the VAT. Two more kinds concern the text: fixed text, the same in every contract, and an option, a choice among several ready wordings, such as prepayment or payment after delivery.

7. Of the four kinds, the derived field matters most for errors: it stores no value of its own and is computed from other fields every time. A quantity of 15 times a price of 12,400.00 gives 186,000.00. VAT at 20% of that sum is 37,200.00, and the total comes to 223,200.00. The program writes the amount in words from the same number, so words and figures cannot diverge, and if the price changes, the whole chain is recalculated.

8. Without derived fields a person types the same chain, and it holds only as long as they stay attentive. The sum line shows 168,000.00 instead of 186,000.00 because two digits swapped places. In the amount in words the person left out the word “three”, so the words say 220,200 and the figures 223,200. The page looks neat, and in reading such mismatches mostly go unnoticed. When a program computes the numbers, this kind of error has nowhere to come from.

9. The program assembles the finished contract: it takes the template, puts into each blank the value of the field with the same name and computes the derived fields itself. For Zerno-Treid that is 15 tonnes at 12,400.00 and a total of 223,200.00. The person fills in a card of seven fields and checks that card, instead of rereading several pages to find what changed.

10. One template yields as many contracts as there are sets of fields: here three, for three different deals. The text is the same in all of them, and the program computes each total from that contract's own quantity and price. When the wording has to change, it is changed in the template, and every later contract comes out with the new wording. The exercise for this part asks you to sort ten fragments of one contract by kind of field.

Who catches the error

1. A contract arrives in different shapes: a crooked scan with a seal, a Word file, or a neat PDF with a table. Each holds values that money and deadlines depend on: the company code, the account number, the amount, the date. Three such contracts show the ways to check a value in a document and which error each way catches. They also show why a neat file deserves no more trust than a scan.

2. How a document looks depends on how it was made, not on whether its data are right. A PDF is usually saved from the same Word file, and a scan is a printed sheet that was photographed. In all three, someone typed the code, the amount and the date on a keyboard or carried them over from an earlier contract. A typing error passes into any format unchanged, so the check is the same for all three.

3. The first check needs nothing but the value itself. The EDRPOU code, the number under which a company is entered in the state register, has eight digits, and the last one is a check digit: it is computed from the first seven so that a typing error shows at once. Each of the seven digits is multiplied by its weight, the products are added, and the sum is divided by 11. For code 31316718 the sum is 96, the remainder 8, and the eighth digit is 8 too.

4. In the scanned contract the same code is written as 31361718: two neighboring digits have swapped places. The products change, the sum is now 91, the remainder 3, while the eighth digit is still 8. Such a mismatch means the code most likely contains an error, and it gets checked against the register. The formula almost always catches a single wrong digit the same way. A remainder of 10 has its own rule: the calculation is repeated with other weights.

5. This kind of check is called algorithmic: it works wherever a value has a formula. An IBAN carries two check digits of its own, and the one in the scan fails them. In the Word contract the product of 15 and 12,400 is written as 168,000 instead of 186,000, and the PDF has the date April 31, which is not in the calendar. Yet code 47645196 from the same PDF passes the formula: it checks how a value is written, not whether the company exists.

6. Only the register answers whether a company exists. The EDR, Ukraine's state register of legal entities, has an open search that shows a company's name, address and director by its code. For code 47645196 from the neat PDF the register finds no entry. That does not yet mean the company does not exist: the error could be in the code itself, so the search is repeated by name. The buyer does have an entry, but the contract says building 6-B and the register says 6-K.

7. What remains are errors that neither the formula nor the register sees: each value is plausible on its own, but they contradict each other. Cross-reading finds them: a person compares different places in one document. The contract is dated May 21, while the annex refers to a contract of May 12. In the preamble the director's initials are O. S., under the signature they are O. V. The warranty in clause 6.1 is 12 months, in the annex 24.

8. An AI assistant, a program that answers a request with text, speeds up all three checks, but the result depends on the wording. To a general “check the contract” it answers confidently and may write “no errors found” without comparing the dates. To a precise “compare the dates in the contract and annex 1” it quotes both dates and shows the mismatch. A confident tone says nothing about how much it actually checked.

9. In each of the three checks the assistant has its own share of the work and its own limit. For formulas it copies codes, amounts and dates into a table, but the computing is better left to a formula, since the model makes arithmetic errors. It searches the register only when the product gives it that access; without access the answer is a guess. In reading it finds the paired places, and a person decides which of the two values is right.

10. The three checks catch different errors, so none replaces the others. You start with formulas, because they are fast and cost nothing, then comes the register query, and the slowest part, reading the links between clauses, stays with a person. A scan, a Word file and a neat PDF go along this path the same way. The neat PDF in this example turned out to have both a date that is not in the calendar and a code that is not in the register.

From clause to date

1. The parties have signed a supply contract, and from that day on they owe each other obligations: pay an advance, bring the goods, accept them, pay the rest. The deadlines for these actions are scattered through the text, and almost none is written as a ready date. The film shows how to turn the clauses of a contract into a list of what has to be done and by what date, and why some of the dates cannot be filled in ahead of time.

2. The list is built one clause at a time. Under clause 3.1 the Buyer pays an advance of 40% of the price, that is UAH 120,000.00, within 5 banking days from the date the Contract is signed. This sentence is split into five fields: who performs, what exactly, the term, the type of days, and the trigger, the event from which the term starts to run. They are written down separately because the last three fields set the final date, and an error in any of them shifts it.

3. The type of days decides which days count. Calendar days run in a row, Saturday and Sunday included, while working days leave out the weekend. The count starts on the day after the event, so from signing on Thursday 10.09.2026, five calendar days end on Tuesday 15.09 and five working days on Thursday 17.09. The same term gives two different dates, so the type of days is copied from the clause word for word.

4. Clause 3.1 calls the days banking days, and the law does not define what a banking day is. The meaning of the term is set by the contract itself, and if the contract has no definition, the last day of the term becomes a matter of dispute. For this example, assume that banking days are the days from Monday to Friday. Under that assumption the count takes in September 11, 14, 15, 16 and 17, and the last day to pay the advance is Thursday 17.09.2026.

5. The trigger, too, is taken from the text of the clause, not from marks on the paper. The scan of this contract carries an incoming stamp dated 11.09.2026: the day the copy reached the records office. Counted from the stamp, five banking days end on Friday 18.09, one day later than the real deadline. Clause 3.1 ties the count to signing, so the correct date remains 17.09.2026.

6. The contract ties the delivery deadline to an event that had not yet happened on the day of signing. Under clause 4.1 the Supplier delivers the goods within 14 calendar days of the day the bank credits the advance to its account. The Buyer may pay on the first day of its term, on the last, or late, and nobody knows in advance which. So the date field says “awaiting event”: a date counted from the expected payment day would be a guess.

7. The trigger date is taken from the document that confirms the event. For the advance being credited, that is the Supplier's bank statement: it shows UAH 120,000.00 arriving on Tuesday 15.09.2026. From that day 14 calendar days are counted, weekends included this time, and the last day for delivery becomes Tuesday 29.09.2026. Only now does the row get a date, and next to it goes the document the event day was taken from.

8. Delivery in turn becomes the trigger for the next deadlines. From its day the Buyer has 5 working days to accept the goods for quality, and the 12-month warranty also runs from it. The signed delivery note starts the payment of the balance: UAH 180,000.00 within 10 banking days. The result is a chain in which each date waits for the event before it, so what is known in advance is the length of each term, not the days on the calendar.

9. Some obligations have a trigger that may never occur at all. They are called conditional: the duty arises only once the event named in the clause has happened. Defective goods are replaced within 10 calendar days after the report, force majeure is notified within 10 calendar days, and on withdrawal from the Contract the advance is returned within 5 banking days. They go into the list without a date, and if the contract is performed without breaches, the date never appears.

10. The analyzed clauses are gathered into one table called an obligations tracker. Each obligation takes a row, and the columns repeat the fields: clause, who, what, trigger, date and status. It is needed because a contract arranges deadlines by section, not by calendar, and the nearest date cannot be seen from the text. A date appears only in rows whose trigger has occurred: the advance by 17.09.2026 at the latest, delivery by 29.09.2026 at the latest.

11. The tracker is reviewed after every event. Suppose the goods were in stock and were delivered as early as Wednesday 16.09.2026, and the Buyer signed the delivery note the same day. The three rows that were waiting for this get their dates: acceptance by Wednesday 23.09.2026, the balance by Wednesday 30.09.2026, the warranty until 16.09.2027. The conditional rows stay empty. Try taking one of your own contracts apart this way: five fields from each clause with a deadline, and a mark for whether the trigger has occurred.