Transactions management

When the client or any other entity pays the invoice, the payment transaction is recorded in your bank account, including transactions for contractors. All transactions can be found by clicking the “Transaction” button for the chosen bank account.

The Transactions view provides a real-time overview of all financial movements across linked bank account. This section helps finance teams track payments, reconcile discrepancies, and monitor cash flow. The view consists of 2 parts: on the top there's graphical representation of balance changes across time, below there's detailed view of each transaction.

What the View Shows:

• Current balance: Displays the total available funds for selected bank account.
• Transaction history: Lists all processed and pending transactions.
• Filtering options: Allows users to filter by date range, contractor, amount, or direction — incoming or outgoing.
• Attachments column: Indicates whether supporting documents (e.g., invoices, receipts) are required.
• Contractor linkage: Highlights missing contractor information that needs updating.
• Each Contractor in the table has clickable icon on the left, so you can easily go to contractor's page to check/update details.

When clicking on a specific transaction, a side drawer opens with detailed transaction management options. This functionality allows finance teams to efficiently review and update individual transactions.

Features Available in the Side Drawer:

• Add Attachment – Upload supporting documents such as invoices, receipts, or contracts. You should also select Received date to ensure compliance.
• Attach Awaiting Files – If documents were already uploaded but not linked to this transaction, they can be attached here. You should only find attachment in the list and click "Attach" button.
• Assign to Budget– Link the transaction to a specific budget for accurate financial tracking. This feature is available only if Budget module is active.
• Categorization – Split the transaction's amount across one or more projects. A sum indicator below the rows shows whether the allocated amounts match the transaction's amount; a mismatch is called out explicitly, and the split is not saved until it is resolved.

When the document already says which project

A cost can be recorded against a project in two places: on the document — the supplier invoice or attachment — and on the payment that settles it. Only one of them is needed, and Flowtly treats the document as the one that counts.

So if the document a payment settles already names a project, the payment cannot be given a project of its own. Categorization on that payment is unavailable, and the drawer says the assignment belongs on the document. The same applies to an outgoing invoice: if the invoice, or the contract it was raised under, names the project, the payment that settles it does not repeat it.

When the document carries the project on its own split or on one of its lines, the drawer names both: Assigned via the document's number → the project. If you can open incoming invoices, the same notice links straight to the document. A payment whose document names no project shows the general notice instead, and its categorization stays read-only too.

The reason is worth a sentence, because it explains a rule that can otherwise look like a missing feature. Two independent records of one cost can drift apart — someone edits the split on the invoice months later and the payment still points somewhere else — and nothing about the numbers would look wrong while they did. Keeping the cost in one place removes the question.

Where to change it instead. Open the document and edit its project split there — see Splitting a Cost Across Projects by Attribute for how the split works, including striking a project out of it. For an outgoing invoice, change the project on the invoice row, or on the contract.

When the payment is still the right place. A payment with no document keeps its own categorization exactly as before. That is the normal case for a cash spend, a bank fee, or a cost whose invoice has not arrived yet — nothing about those changed.

Payments already recorded in both places keep working and keep their numbers; the budget has always counted such a cost once, not twice. They can be tidied by clearing the split on the payment, which stays available so that the record can be moved onto the document.

Giving the document a project when the payment already has one. The rule also works in the other direction. However you set the document's project (editing its split by hand, using one of the prefill buttons, or accepting a suggested project), Flowtly first checks the payments that settle it:

• If a payment names the same project for the same amount, the document takes the project and the payment's own copy is removed, so the cost is recorded once, on the document, for the same total.
• If a payment names a different project, or a different amount, nothing is changed and Flowtly says why. Clear the project on that payment first, then set it on the document. When you accept all suggestions at once, this one is listed as skipped and the rest are still applied.

Transaction Details Section Contractor Selection – Assign or update the contractor associated with the transaction. Connected Month – Define the relevant financial period for reporting purposes. Transaction Amount & Balance After Transaction – Displays financial impact and updated account balance.

Attachments Section Here you have possibility to review linked attachments if present, download it or completely remove in case if it was incorrectly matched.

There's an option to directly download the MT940 file at the top right corner of the Transactions item from the main menu. After downloading the file, it will be automatically attached to the designated bank account.

An uploaded statement file is assigned to a bank account by comparing the account number in the file with the account numbers configured on your bank accounts. A bank account saved without an account number cannot take part in that comparison and never receives a statement automatically - see Bank Accounts for where to fill it in.

Which file to export from your bank

MT940 is a standard bank-statement format — a plain text file, not a spreadsheet, a PDF or an XML report. Flowtly accepts it with any of the extensions banks give it: .sta, .txt, .mt940 or .940.

Most online banking offers several exports, and only the MT940 one can be imported here. The names differ between banks, but the distinction is the same everywhere:

• MT940 — this is the one. Look for it by name; some banks label it statement in MT940 format or SWIFT MT940.
• MultiCash, MT942, or an export described as an intraday or balance report — a different format, even where the same menu offers it beside MT940. It will not import.
• An XML export, or anything labelled as a report or a file-structure export — not MT940 either, whatever file extension it happens to carry.

If your bank offers more than one and you are unsure, export the one named MT940 and upload that.

If the upload is refused, the file is not in a format Flowtly can read — most often because it is one of the other exports above rather than MT940. Try the MT940 export specifically. If that is refused too, send the file to support: the format varies between banks, and some need work on our side before they can be read.

Every refused file is kept. Below the list of statements on the Transactions page, the Refused uploads table shows each one with the time it was refused, who uploaded it and the reason. Use the download icon in its row to get the exact file that was sent, for example to correct it or to pass it to support. Some older refused files have no download icon because their copy was not linked to the entry.

What the import message tells you

When the file has been read, a message reports how many transactions were added — which is not always how many the file contained. Statements overlap: a movement Flowtly already holds is recognised as the same movement and is not entered a second time, so re-uploading a file, or uploading one covering days already imported, adds only what is genuinely new.

The message is worded for what happened.

• Everything in the file was already held. It says so — All 13 transactions from this file were already in the system. — and appears as information rather than as confirmation that something was added, because nothing was.
• Some movements were new and others already held. Both numbers are given: 5 transactions imported. Already in the system: 8.
• Every movement was new. The message reports the number imported.

A movement is recognised as one you already hold when its dates, amount, reference and description all match. Two separate payments that happen to share a day and an amount are never merged into one: each keeps its own row, and each is recognised separately on a later upload. The same applies to a file uploaded again after your bank changed how it words a movement: if the description of a line differs from the one stored, that line is treated as a new movement and is added.

A count lower than the number of movements you can see in the statement is therefore the expected result on an overlapping upload: it means nothing was duplicated, not that rows were lost. If a movement you expected is genuinely absent, look for it in the transaction list first — it may have arrived with an earlier statement.

Transactions for Contractors

How does it work?

Pay the contractor via your bank (outside Flowtly). Keep the payment confirmation or bank transaction details for reconciliation. To reflect the payment in Flowtly, import your bank statement (MT940 file) into the system. Flowtly will automatically match payments with contractor based on the amount, payment reference, and contractor details. If Flowtly doesn’t automatically match a transaction, you can manually assign it to the relevant contractor by selecting it from awaiting attachments.

Contractors that belong to an internal cost group are left out of these automatic suggestions, so an internal transfer is not proposed as a supplier payment even when the contractor's name appears in the transaction description. You can still assign such a contractor to the transaction yourself.

Navigate to the Contractors item in the main menu and select the relevant contractor. Under the Transactions tab, all payments related to that contractor will be listed. This tab provides a structured overview of all financial transactions related to a specific contractor, making it easy to track historical payments, missing attachments, and financial trends.

Key Features of the Contractor Transactions Tab:

• Graphical Overview – Displays a visual breakdown of transactions over time.
• Detailed Transaction List – Shows all transactions linked to the contractor, including payment dates, amounts, and statuses.
• Attachment Status – Indicates whether a transaction has an associated document (e.g., invoice, proof of payment).
• Financial Trend Analysis – Helps monitor contractor expenses across months and years.

When clicking on a transaction, a side drawer opens with detailed transaction management options. This functionality allows finance teams to efficiently review and update individual transactions. Details described in Features Available in the Side Drawer section.

You can also manage transaction attachments here, similar to the bank account transactions.

Transactions for Clients

How does it work?

To reflect client payments in Flowtly, import your bank statement (MT940 format) into the system (Transactions item in the main menu). Flowtly will automatically detect incoming payments and attempt to match them with existing invoices for clients. If the system finds a match, it will assign the transaction to the correct invoice under the corresponding Client Profile. The Payments tab in a Client’s profile gives a structured overview of all issued invoices and their respective payments. If a payment is not auto-matched, you can manually assign it by detecting the invoice under the Payments tab and click "Assign transaction". It will open a modal with imported transactions that were not matched or with not full amount of it used. You can also provide transaction amount here.

After that, the transaction will be matched with the invoice, and paid amount status and amount will be updated. You can remove already assigned transaction. This will also lead to recalculation.

Example use cases

• Reconciling Bank Statements: Easily match imported bank transactions with internal records to ensure all financial movements are accounted for and discrepancies are resolved promptly.
• Tracking Contractor Payments: Monitor all outgoing payments to contractors, link them to specific contracts or projects, and ensure all supporting documents like invoices or payment confirmations are attached.
• Managing Client Incomings: Automatically or manually assign incoming client payments to outstanding invoices, updating their payment status and keeping an accurate overview of receivables.
• Audit Preparation: Ensure all transactions have necessary attachments (invoices, receipts) linked, facilitating quicker audits and compliance checks by having a centralized and organized record.