The Contract Template That Fills Itself — and the Fields It Leaves Blank on Purpose
A contract is, in most small firms, the same text every time. What actually changes is a handful of facts: who the parties are, their tax numbers and addresses, the amount, the dates. Every retyping of those facts is a chance to mistype a registration number or to copy the address of the previous client into a document that will be signed. The template exists to remove exactly that step, and nothing else.
Inside Firmspace a template is plain contract text with placeholders in double braces: {{number}}, {{customerTaxId}}, {{start}}, {{firmIban}}. The placeholders are Latin and without grammatical cases on purpose: the text is written by a person, and substitution must not force declensions like {{to-the-customer}}. Capitalisation and spaces inside the braces do not matter, so {{ customerTaxId }} works exactly like {{customertaxid}}.
Values are resolved in a strict order, and the order is the whole design. First comes what a person typed in the form of this particular contract — a correction for this one client. Second, the client card: the contact and the company with all their details. Third, the firm's own data from the accounting settings and the details-for-contracts section. The stronger source wins; a value from the card never quietly replaces one that was entered by hand for this document.
Behind a client there are often two records: a contact and a company. The template does not ask which one to use. Personal data — name, passport, birth date, personal tax number — is taken from the contact; company data — legal name, codes, bank, authorised person — from the company. For fields both could fill, such as address, phone, e-mail or tax number, the company wins when a company is linked, and the contact fills in when it is not.
Before anything is printed, the contract form shows a block called data for the contract. It reads the chosen text, finds the placeholders it contains and lists only those — no catalogue of two hundred fields, just the ones this document actually needs. What can be pulled from the card and the firm's settings is already standing there. What cannot be found is marked as missing and outlined in amber. A value typed into that block applies to this contract only.
There is a checkbox under that block: save to the client card. It turns the form into a small data-entry tool instead of a dead end. A passport number typed once for one contract goes back into the contact record and is there for the next contract, the next invoice, the next export. This is how a client card becomes complete in practice — not through a data-cleaning project, but because someone needed the value for a document that had to go out today.
Here is the detail that decides whether the template can be trusted. A standard requisite with no value is replaced by an empty string: the line in the document is simply blank. A label the system does not recognise — a typo, or a custom field nobody filled in — stays in the text exactly as written, {{like this}}. So a typo is visible on the printed page, while a blank line comes from missing data. Both are caught earlier, in the same block, by the missing marker — but only if someone looks.
Formatting is handled for the values that need it. Dates stored as 2026-03-14 are printed as 14.03.2026, because that is how a contract reads in German, Ukrainian or Uzbek practice. The contract amount is printed with its currency rather than as a raw number. The contract number is not a placeholder anyone should type: it comes from the numbering and its prefix, and the same is true of invoice and quote numbers. These are settings, not template logic, and nobody in the chat should be inventing them.
A real contract usually arrives as a file from a lawyer. The template editor accepts it: .docx, .txt or .md up to 3 MB. The text is extracted into the editor, and Word markup is cleaned against a whitelist — paragraphs, headings, bold, italics, lists, links, images. The file itself is not stored. After that the person drags the needed placeholders from a palette of about two hundred fields, or adds a custom field with its own key, label and type, and says whether the value comes from the card or is entered by hand.
Old templates do not break. A plain text with placeholders keeps working as it always did; the rich editor turns it into paragraphs with labels the first time someone opens it. In the editor a label is stored as a small tagged span, which is why the same label can be dragged, moved and deleted like a word. What matters is that both forms render through the same substitution: one function for the preview in the browser, the same logic for the PDF on the server, so what you saw is what the client receives.
A firm rarely needs one template. Rent, employment, services, a framework agreement with a regular client — each has its own text and its own set of fields. Templates are unlimited and live next to the accounting settings, in the finance settings section. When a contract is created from a template, it remembers both the template and its own copy of the text. Editing the template tomorrow does not rewrite a contract that was signed yesterday: the document keeps the text it was printed with.
The assistant has its own, narrower part. Creating a contract opens a draft: number, customer, amount, currency, optional dates; a matching contact is linked or created, and no separate search is needed first. Another action moves a contract from draft to active, to completed or cancelled. And a drafted text can be saved as a new document in the contract store, always marked as an AI draft for a specialist to review. What the assistant does not do is type requisites into the document: the values are pulled from the records when the file is rendered, so an invented tax number has no way into the PDF.
Two honest limits. First, a template is a working frame, not legal advice: the text is written and checked by the firm's lawyer, and the built-in sample only gives a starting shape. Second, a filled template is only as complete as the records behind it — the substitution cannot create a value that nobody entered. The checklist before the first real contract is short: firm details filled in the accounting settings, the client card filled in or the missing fields entered by hand, no brackets left in the preview, dates and currency checked, and the number taken from numbering rather than typed.