Contracts

Contracts in Flowtly define the financial terms of your engagements — a structured set of payment schedule lines, optionally linked to a budget. Each contract specifies when payments are due, their amounts, and the direction (supplier invoice or client billing), giving you full visibility over committed cash flows.

Key concepts

• Payment schedule lines — individual line items defining amount, due date, and payment direction (supplier or client)
• Budget linkage — a contract can optionally be attached to one or more budgets, which act as the financial envelope for the engagement
• Direction — supplier contracts track costs you owe; client contracts track revenue you expect to receive
• Cyclic flag — a contract can be marked cyclic to indicate a recurring/ongoing relationship; this is advisory only, and payment lines are still created one at a time rather than auto-generated from an interval
• Document attachments — attach signed contract files, amendments, or supporting documents directly to the contract record
• Payment terms — how long the counterparty has to pay, what that period is counted from, and whether payment falls due in advance or in arrears
• Counterparty — who the contract is with. Optional: a contract can be created and kept without one
• Automatic reading — upload a signed contract and Flowtly reads the parties, dates, payment terms and prices from it. Where a second attempt could help, you can run the reading again from the contract's documents, for example after correcting a scan
• Completeness — a contract is checked for the details planning needs, and a contract that will never have one of them can say so; see Contract completeness checks
• Uploading several at once — drop a whole batch of signed contracts: the upload shows each file's progress ("3 of 20 uploaded") and then its state, and you stay on the contract list while it runs. Every upload waits in Awaiting sorting with its state — still being read, ready to review, or could not be read, with the reason and a way out: Re-extract when a second pass can help, Upload again when the file itself is damaged or illegible. A file's review opens when you click it
• A contract that is already in Flowtly — if you upload a file whose exact contents Flowtly already holds, it does not create a second contract. The file's row says This contract is already in Flowtly and links to the contract that has it. Skip is the default. Upload anyway creates the new contract all the same. In a batch the other files carry on, and Skip all duplicates answers every duplicate at once. Attaching a file to an existing contract is never refused
• Rates and total value — some contracts never state a total. A lease priced per m² states a rate, an area and a term, and the total is not written down anywhere. Flowtly records the rate exactly as the contract prints it and leaves the total empty rather than inventing a figure; enter the term and it offers a calculated total you can accept
• Amendments — what the contract's value, area, per-period amount and dates became, and from which date, recorded on the contract while the as-agreed values stay as they were. A price line can be set to follow the area in force, so an area measured after signing reaches the rent; see Contract amendments
• Organisation-specific reading rules — for some organisations, Flowtly staff configure rules that change how a particular kind of contract is read: which direction it stores, a free-text instruction for an unusual arrangement (for example, a development manager's lease where only the fit-out contribution is a cost to the organisation, not the rent), and which contract parameters to fill in alongside it. When a rule matches, the review screen shows which one applied and the parameters it read. A lease whose required amount cannot be found is booked as a cost with no amount or schedule and a needs review flag, rather than a guessed figure. The same flag is raised, and no payment schedule is written, when the instalments found for the required amount do not add up to all of it (for example, only one of two equal halves), so a schedule you entered by hand is kept

What a budget needs from a contract

Two things, and a contract that is missing either contributes nothing to planning. First, the budget has to be able to reach the contract: through the project the contract is linked to, by attaching the contract to that budget directly, or through budget tags. Second, the contract needs a schedule — the budget reads the payment schedule lines, so a contract with none adds no planned figures however it is linked. Neither a document nor a counterparty is required for any of this: you can record an agreement you have no file for, and one whose other party is not yet decided, and it will still plan.

A contract does not need a counterparty

The counterparty field is optional, and leaving it empty is a legitimate, lasting state rather than an unfinished one.

Plenty of real contracts exist before the other side does:

• a tender that has been submitted and not yet awarded
• a tenancy whose current tenant is expected to be replaced
• a cost fixed by an official decision — a levy, a permit, a rate set by an authority — where there is no supplier to name at all

In each case the amounts, the dates and the direction are known and worth planning against long before a name is. Create the contract now and add the counterparty when there is one to add.

A contract can also become counterparty-less on its own: if the counterparty record is later deleted, its contracts survive and simply lose the link. Nothing is removed and no payment schedule line is affected.

Two limits worth knowing:

• The contracts list cannot yet filter for "no counterparty". You can filter to a particular counterparty, but not to the absence of one. Sorting the list by counterparty groups the empty ones together, which is the nearest thing available today.
• Everything else on the contract still applies. Name, direction and currency are required as usual; only the counterparty is optional.

Suggested counterparties when reviewing an uploaded contract

When Flowtly reads an uploaded contract, the review screen suggests existing counterparties the document may be about. Nothing is linked until you choose one.

• A matching tax ID (NIP) comes first. It is the strongest evidence and is listed at the top.
• Names are compared as whole words, ignoring the legal form. "LPP S.A." and "LPP Spółka Akcyjna" count as the same name, while a short name is never matched just because its letters appear inside another word.
• Identical records are shown once. If a counterparty exists several times with the same tax ID and the same name, you see one suggestion rather than a list of look-alikes.
• Clients and suppliers are both searched when the direction is a guess. If Flowtly could not confirm which party is your organisation (typically because your organisation had no tax ID when the contract was analysed), the suggested direction is marked unverified and both clients and suppliers are searched, the ones matching the suggested direction first. The tax ID is set in Invoicing settings → Billing data → Company tax identification number. The mark records the moment of analysis, so setting the tax ID afterwards does not clear it on contracts already read: check the direction on the contract and correct it if needed.

At most five suggestions are shown. If the right counterparty is not among them, pick it by hand or create a new one.

Where each value came from

On the review screen, each value Flowtly read out of the document shows where in the document it found it: the page and the contract's own label for that passage, for example p. 4, § 4 ust. 2. The label is copied exactly as the contract writes it, not translated, so you can look for the same words on the page.

Click the citation to open the contract at that page and check the value against the signed text.

A citation appears beside the name, currency, total, start and end dates, the cyclic switch, the counterparty, the project the contract names, each payment line and each contract parameter. A value with no citation is one Flowtly could not locate in the document. It does not guess a page, so check that value yourself before saving.

Suggested project when reviewing an uploaded contract

When a contract names a project, phase or site, the review screen shows the name as the document writes it, for example The contract names "Etap II". It could be:, followed by up to five of your projects that may match it, the most likely first.

• Nothing is assigned for you. The suggestions are names to look at, not buttons. Choose the project in the project field just below, even when there is only one suggestion and it looks certain.
• "No project of yours matches it" is an answer, too. When the contract names something that matches none of your projects, the screen says so instead of staying silent. Usually it means the project has not been created in Flowtly yet.
• A contract that names no project shows nothing here, and neither do contracts read before this suggestion existed.

Price lines

The Prices section of a contract, and the prices on the review screen of an uploaded contract, list each price the contract sets. Each line reads the same way:

• What the price is: the kind of charge, such as rent or a service charge. In organisations that use the property-management features, the kind is followed by what the line covers, such as Rent · parking spaces or Service charge · common areas. A line that does not say what it covers is marked no subject, so a gap is visible rather than read as rent for the whole premises.
• The price: the rate in the contract's own unit, with the currency stated once and the word net beside the price.
• The multiplier: what the rate is multiplied by, with its unit, such as × 4 m². A line priced by a plain count reads × 2 pcs.
• A line priced by the measured area explains on the line itself that the m² is what was surveyed after handover, not the figure written in the contract. See Contract amendments.

Payment schedule lines in more than one currency

Each payment schedule line has its own Currency, so one contract can mix currencies, for example rent in euro and a service charge in złoty. A new line takes the contract's currency and is labelled Contract default; a line in any other currency is labelled Differs from contract. Choosing the contract's currency again makes the line follow the contract, including a later change to the contract's currency. Changing a line's currency only relabels its amount: nothing is converted. The currency of a line that has already been invoiced cannot be changed. The schedule generator can create lines in another currency too; a split of the contract total always stays in the contract's currency.

How the schedule adds up depends on its currencies:

• Every line in the contract's currency: the lines are summed and checked against the contract total, as usual.
• Lines in more than one currency: every amount on the schedule, on the lines, in the totals and in the delete confirmation, is named by its currency code, such as EUR or PLN, rather than a symbol. The totals show one sum per currency, and the contract total is not compared with them, because a sum of euro and złoty would be a wrong figure.

An invoiced line shows the number and the currency of its invoice beside View invoice, for example INV/2026/10/007 · PLN. When the invoice is in another currency than the line plans, the line says so, for example The invoice is in PLN; this line plans EUR. The line itself stays read-only: to correct the difference, correct the invoice. Someone who cannot view invoices sees the link without the invoice's currency.

The converted total

A schedule whose lines mix currencies also shows a converted total under its per-currency totals, for example Converted total in EUR, marked CONVERTED. It is always in the contract's currency and is for comparison only: the contract itself states no single total across currencies, so nothing is checked against it.

Each line in another currency than the contract shows its converted amount under its own amount, with the NBP exchange rate used and the date of the NBP table the rate comes from, for example ≈ 1 972,25 EUR · NBP 4,2591 · 30/09/2026. A line in the contract's currency shows no conversion. The rate depends on the line:

• An invoiced line converts at the NBP mid rate of the last weekday before its invoice was issued.
• An open line converts at the latest NBP table. The total names the date of that table.
• An invoiced line whose invoice you cannot view converts like an open line, at the latest table.

When NBP published no table for the day a line asks for, the rate comes from the last table published before it. On an invoiced line this is marked older rate beside the table date, and the total says that some lines convert at an older NBP table. A Monday invoice that takes Friday's table is not marked, because Friday is the weekday before it.

A line whose currency pair has no NBP rate at all says No NBP rate for and the date. It is left out of the converted total rather than estimated, the total is marked CONVERTED · PARTIAL, and it names the amounts it left out. If the rates cannot be read at all, no converted total is shown.

Setting the currency of several lines at once

To relabel several lines in one go, tick the checkbox on each open line you want to change. Invoiced lines have no checkbox: they keep the currency they were invoiced in. A bar appears with the number of lines selected, a currency picker for Set currency, the button Apply to N lines and Clear.

Once you pick a currency, and before anything is saved, the bar shows what will happen: the amounts stay as typed and only the currency changes, with an example from your selection such as 8 400,00 EUR becomes 8 400,00 PLN, not a converted figure. Each selected line shows its change, for example EUR → PLN. To convert an amount rather than relabel it, edit the line itself.

Applying changes only the lines that are not already in the chosen currency, and the count on the button leaves the others out. If every selected line is already in it, the bar says so and offers nothing to apply. Choosing the contract's currency makes those lines follow the contract again, exactly as choosing it on a single line does. A line that could not be changed stays selected so you can try again; the rest leave the selection.

Payment terms

A contract states three things about when its invoices fall due, and Flowtly holds each one separately rather than collapsing them into a single number:

• Payment deadline (days) — the number of days allowed.
• Counted from — the date the deadline runs from: Invoice delivery, Invoice issue, Start of period, or An event. Delivery and issue are kept apart deliberately, because they are genuinely different dates and many contracts bind the former.
• Payment — In advance means the amount is paid before the period it covers, such as a month's rent due at the start of that month. In arrears means it is paid after the period, for what has already been delivered.

Counted from and Payment each have an information icon beside them in the form, which gives the same explanation where you are choosing.

An empty deadline means the contract is silent on the subject. That is a different statement from a deadline of zero days, and a different statement again from payment in arrears — so the fields are left blank rather than defaulted, and opening a contract never writes in a term the document does not actually contain.

These fields appear both on the contract itself and on the screen where an uploaded contract is reviewed, so terms read out of the document can be checked and corrected in the same place they were found.

The due date on an invoice comes from the client, not from these fields. They record what the signed document says; they do not drive invoicing. When you raise an invoice from a payment schedule line, its due date is the day you issue it plus the Due days on the client record — the payment term you keep against that customer, which is 20 days until you change it. The date stays editable on the invoice afterwards, and nothing later overwrites what you type in.

Invoicing clauses

Some contracts state rules that matter every time an invoice is raised against them: which exchange rate converts the amount, how the price is indexed, how the service charge is settled. The Invoicing clauses section on a contract, directly under its prices, keeps those sentences with the contract so nobody has to reopen the signed document to find them.

Each clause has three parts:

• Kind - Currency conversion, Indexation, Service charge settlement, or Other for a rule that fits none of these.
• Clause, in the contract's own words - the sentence quoted exactly as the contract writes it, in the contract's language. Do not translate or summarise it: a rate taken "on the day before the invoice date" and one taken "on the invoice date" give different invoices, and a paraphrase can lose exactly that difference.
• In the document - optional: where the clause sits, using the contract's own label, for example § 5 ust. 3.

Where clauses come from. When Flowtly reads an uploaded contract, it also picks up invoicing clauses where it finds them, and records them as written. Clauses can also be added, edited and deleted by hand at any time. Reading the document again replaces only the clauses the reading found itself; a clause somebody added by hand is never removed or overwritten by a later reading.

The section is shown even when the contract has no clauses yet, so the first one can be added. Adding, editing and deleting clauses is available to people who manage contracts or budgets; people who can only view contracts see the clauses without the controls.

Nothing is applied automatically. A clause is information for the person raising the invoice. Flowtly does not convert, index or recalculate anything because of it: amounts and exchange rates stay exactly as you set them. When an invoice raised from the contract is opened for editing, its clauses are shown on the invoice form; see Invoice list and creation.

Deleting a contract

A contract that other records still point to cannot be deleted. Flowtly refuses the delete instead of quietly cutting those links. The records that block it are invoices, payment documents, deals, signature requests and initial budget items linked to the contract, as well as budgets that use it. Unlink them first, then delete the contract.

A deleted invoice does not block the delete. Only invoices that still exist count. An invoice that was deleted earlier is kept in its deleted state and simply loses its link to the contract.

A deal cannot be unlinked from its contract. A won deal keeps its contract link for as long as the deal exists, so the refusal message says so rather than asking you to clear it. To delete a contract a deal points to, delete the deal first.

A contract's own parts are not blockers. Its payment schedule lines, documents, events, amendments, clauses and work lines are deleted together with it.

Limits on contract fields

A contract is rejected on save, with a message, when:

• its name is longer than 255 characters;
• the amount per period is larger than 99,999,999,999.9999;
• the turnover minimum is larger than 99,999,999,999.9999;
• its end date is earlier than its start date;
• the event that starts its payment schedule belongs to a different contract.

Two checks run in the form itself, before anything is sent: a contract's Name cannot be emptied, and a payment term must be a whole number of days. The field says what is wrong and nothing is saved until it is corrected.

A contract's fields save themselves as you leave them, so a rejection arrives without a Save button having been pressed. The field itself then says "Not saved", with the message, and keeps saying it until that field saves successfully. The value you typed stays in the field, so it can be corrected and the field left again.

The contract form works like every form that saves as you go: the last change can be undone for 8 seconds, a change made without a connection waits and saves itself, refused changes are counted at the top with a jump to the first, and closing the contract drawer stores what you are still typing and asks before a change that was not saved is thrown away. See Forms that save as you go. A new contract is different: nothing is stored until you press Save.

Contract documents

Contract and annex files are attached to the contract record and listed on it. A document can be previewed in place — the file opens in a viewer without leaving the contract — which is usually all that is needed to confirm what was signed. Anything the viewer cannot render is offered as a download instead.

A separate Download action remains alongside the preview, because getting the signed file out of Flowtly and reading it are different jobs.

Deleting a document is permanent, and two documents cannot be deleted at all. Removing a contract document is available to people who manage contracts, and it asks for confirmation naming the file first, because there is no undo and no recycle bin — the file is gone from the contract record. Two cases are refused outright, and Flowtly says which one you have hit rather than reporting a generic failure:

• The contract's only contract document. A contract needs one contract-kind document to remain readable as a contract, so the last one cannot be removed. Upload the replacement first, then delete the old one.
• A document an amendment records as its signed annex. Deleting it would leave the amendment pointing at nothing, so the amendment has to stop referring to it first.

Annexes and any further contract documents beyond the last one delete normally.

Adding a document to a contract that already exists. A contract file you attach is read automatically, just as a new upload is, but the reading only fills fields that are still empty. A name, direction, amount, dates, currency, payment terms, schedule or prices already on the contract are never overwritten, because they may be yours. What the document says about those fields is kept with the document as a suggestion. An annex is stored as it is and not read: an annex changes part of a contract rather than restating it, so reading it as though it were the whole contract would give wrong values. To read a document again and let it replace the contract's fields, use the re-read action on the document. It asks for confirmation first.

When automatic reading fails

A reading that does not succeed says which kind of failure it was, rather than reporting a bare failure, and Re-extract is offered only where running the reading again could actually help:

• The document could not be read — usually a photo or a low-quality scan. Re-reading the same file will not produce a different result: reject it and upload a clearer PDF.
• The file has no content — the upload may have been interrupted. Upload the document again.
• The reading could not be finished — the problem was on Flowtly's side rather than with your file, so re-extracting usually works.

In every case the fields stay editable while the file is under review, so a contract can be completed by hand and saved as usual instead of waiting for a successful reading.

Re-extracting analyses the document again and overwrites the fields with what it finds, including any corrections made in the meantime, so it asks for confirmation first.

Contract parameters

Some organisations have a set of contract parameters configured for their contracts — the same typed fields already used for budgets, projects and properties. When a document matches an organisation rule that names a parameter set, automatic reading fills in what it can find (for example, the stated rent terms on a lease whose cost to your organisation is something else entirely) as reference information alongside the contract. A parameter you have already filled in by hand is never overwritten by a later reading.

Example use cases

• Comparing a mixed-currency lease: Read the converted total of a schedule with rent in euro and a service charge in złoty, in the contract currency at NBP rates, to see what the agreement is worth overall.
• Fixed-fee project billing: Create a client contract with monthly payment milestones linked to a project budget, so you always know what is invoiced and what remains.
• Vendor retainer: Set up a supplier contract marked as cyclic for a software licence or consultancy retainer, and create each new payment line as it comes due.
• Subcontractor payments: Link a supplier contract to a project budget to track subcontractor costs against the planned spend and ensure no line exceeds the budget ceiling.
• Checking a term before chasing payment: Read the deadline and what it is counted from directly on the contract, rather than reopening the signed document to find the clause.
• Confirming what was signed: Preview the attached contract file in place to check a detail, without downloading it first.