A dedicated operations and procurement system built on the Flow Procurement platform

How a tailored solution connected purchase requests, approvals, orders and invoice intake for an anonymized customer.

The starting point

Flow Procurement's first customer was a key player in the transport industry in Poland. The customer needed one system for purchasing across the business instead of ad-hoc purchases. The organizing principle was simple: every purchase becomes an order. That meant capturing the need, applying the relevant approval rules and keeping the supplier order connected to the later invoice.

The solution was delivered as a tailored system on the Flow Procurement platform. It uses the same procurement core, extended and configured for the customer's processes. It runs in the cloud with a Polish interface. The work focused on how people request, review and record purchases. A shared core provided the procurement foundation, while configuration and extensions addressed the required workflow.

One request for different kinds of need

Guided buying brings several sources into a single request. People can choose from an internal curated catalog, request warehouse items that need re-ordering, search external supplier catalogs through supplier APIs or describe a free-text item. These sources can be mixed in one request. The buyer can then review the need as a whole instead of handling separate messages for each source.

This makes data ownership a practical part of the process. Catalog descriptions and units need maintenance. Warehouse re-ordering needs a clear item reference. External searches need a usable supplier connection. Free-text items need enough information for a buyer to act. The interface can collect those lines together, but people still need to resolve incomplete or ambiguous information before an order is ready.

Approval rules built from blocks

The approval workflow uses ordered levels and amount thresholds. Within a level, category-specific blocks take precedence over general ones. Parallel approvals within a level require all the relevant approvals before the request proceeds. Approver groups serve a different purpose: one active member can close the group's step. These structures let the configuration express distinct responsibilities without treating every approval as the same kind of review.

The rule set is frozen as a snapshot when a request is submitted. A later configuration change does not alter requests already in flight. That preserves the basis for the review and makes the path understandable afterward. Buyer edits are audited with a field-level diff, so reviewers can see which values changed. The combination matters because an approval needs to refer to a known request under known rules.

From approval to order and invoice

Approved requests turn into purchase orders to suppliers. The order becomes the reference for what was agreed and what later needs to be connected. Supplier invoices are imported from KSeF and linked to orders. The integration is built on the official KSeF API 2.0. Linking the invoice is part of the purchasing record, with the supplier data and access setup treated as implementation work.

The general lesson is to prepare those dependencies alongside the screens. Supplier tax IDs and order references need owners. KSeF certificates and permissions need a project task and a responsible person. An integration can be technically connected while users are still missing the data needed for a reliable link. Bring buyers and invoice owners into preparation so both sides agree what a usable order record contains.

AI proposals with a human decision

The tailored solution also includes AI-assisted email intake. A shared mailbox is read automatically. Each message is classified by an AI model using typed judgments for structured fields. The result is a proposal that a person can approve, reject or link to an existing record. Nothing is created without that click. Automatic replies pass a guardrail check before they go out.

This keeps the proposal distinct from the decision. The person reviewing it can see whether the message concerns an existing purchase or a new need. A structured classification helps route the work, but it does not authorize a purchase. The broader lesson is to keep a human in the loop for AI proposals and make the next action explicit. A useful draft should reduce re-entry without hiding the decision it asks someone to make.

Lessons to carry into another implementation

Configure approval rules before go-live. A workflow with no rules approves everything, so an empty configuration needs deliberate review. Freeze the rules per request so later changes cannot rewrite an open review. Retain field-level edits so approvers can understand what changed. Treat supplier data and KSeF certificates as project tasks with owners, rather than details to finish after rollout.

The same lessons apply to a smaller pilot. Start with real request examples, inspect the selected approval path and check how the resulting order links to invoice intake. For AI proposals, test approval, rejection and linking to an existing record. Keep the human decision visible throughout. Results will be published once they have been measured together with the customer.