How do you get PDF or paper delivery notes into a warehouse system?​

An AI agent reads the delivery note — PDF or scan — and extracts the lines: item, quantity, unit, references. It matches them against the open purchase order, drafts a goods receipt, and flags any mismatch between what was ordered and what arrived. A person confirms before stock moves. Unlike a structured import, it doesn't need the supplier to send CSV or XML, because it reads the document the way your warehouse clerk does — and escalates only the exceptions.

Why a normal stock import doesn't help​

Stock import routines need a structured file the supplier exports. A PDF or paper delivery note isn't structured, so there's nothing to import and it's retyped by hand. Where a supplier can send a clean CSV or XML feed, use it — it's simpler than anything custom. The AI step is for the many suppliers who only ever hand you a document a person has to read.

Who has this problem​

Who has it: a distributor receiving deliveries from dozens of suppliers, each with its own delivery-note layout, none of them sending structured files — so the warehouse retypes every receipt and only spots a short delivery weeks later at stock count.

Reading the note is the easy half; the value is matching it to the order and catching mismatches at the door. It's the same shape as invoice data extraction, one door earlier — and one concrete case of the broader problem of tools that don't talk to each other, where the supplier's "tool" is a piece of paper.

Where AI helps — and where it stops​

AI is worth it because the step needs reading and matching: pulling lines from a varied document and reconciling them against the order. Once the lines are clean and matched, updating stock is plain automation. The line holds: AI proposes, a human confirms before stock moves. Our AI solutions overview shows where that fits into a controlled process.

Who it makes sense for​

• delivery notes arrive as PDFs or paper, not structured files,
• someone retypes each one into a goods receipt,
• mismatches between order and delivery get caught late, not at the door,
• your suppliers won't switch to a structured delivery feed.

Want to see it on your own delivery notes? Get a free diagnostic — we look at a sample from real suppliers, tell you honestly whether a structured feed would be simpler, and if not, show exactly what we'd build, the impact and the cost. No obligation.

How do you process orders that arrive as free-text e-mails or PDFs?​

An AI agent watches the order inbox, reads each e-mail and any PDF attachment, and extracts the fields that matter — product, quantity, variant, delivery. It maps them to your product codes, assembles the record your system expects, and a person confirms it before it's booked. Unlike structured import or EDI, it doesn't need the customer to send clean XML or CSV, because it reads the message the way a human would — and escalates only what it isn't sure about.

Why a normal import or EDI doesn't help here​

Import routines and EDI need structured data — a file in a fixed format the sender exports. Free-text e-mails and scans have no such structure, so there's nothing to import, and the order gets retyped by hand. If your bigger customers can send clean XML or CSV, use that — it's cheaper than anything custom. The AI step is for the orders that will never be structured: the ones a person types in prose.

Who has this problem​

Who has it: a manufacturer whose customers e-mail orders in free text or as PDFs — each with its own layout, its own shorthand for products — and where two people spend part of every morning retyping them into the production system, occasionally keying the wrong quantity.

This is the same shape as invoice data extraction: reading a document is the easy half; the value is mapping it correctly to your codes and keeping a human on the exceptions. It's one concrete case of the broader problem of tools that don't talk to each other — here the "tool" on the other side is a person's e-mail, which no connector will ever cover.

Where AI helps — and where it stops​

AI is worth it here because the step needs reading and judgement: understanding prose, resolving "the usual" against order history, matching a product named three different ways. Everything downstream — writing the record, updating stock — is plain automation once the fields are clean. And the line holds: AI proposes, a human confirms anything that gets booked. Our AI solutions overview shows where that fits into a controlled process.

Who it makes sense for​

• a meaningful share of your orders arrive as e-mails or PDFs, not structured files,
• someone retypes them into your ERP or order system every day,
• your customers won't (or can't) switch to a structured order format,
• occasional retyping errors cost you in wrong quantities or mis-shipments.

Want to see it on your own order inbox? Get a free diagnostic — we look at a sample of real orders, tell you honestly whether a structured feed would be simpler, and if not, show exactly what we'd build, the impact and the cost. No obligation.

What do you do when your business tools don't talk to each other?​

First, resist the urge to build. Check whether a ready-made connector already exists for your combination of tools — many accounting, e-shop and CRM systems ship off-the-shelf integrations, and if one fits your data, use it: it's cheaper than anything custom. A custom bridge or AI agent earns its place only when no connector covers your specific tools, or your process is non-standard enough that a generic integration can't express it. The goal is fewer hours retyping and fewer errors — not more software.

Buy or build? The honest fork​

Buying beats building far more often than vendors admit. Buy the ready-made connector whenever one exists for your exact tools and it covers the data you move. Build custom only when the connector doesn't exist for your combination, when it moves only part of the data, or when the work is a judgement step — reading a document, deciding where an entry belongs — that no fixed connector performs.

Three situations where no ready connector fits​

1. The tools are standard, but your combination isn't​

Who has it: a wholesaler taking orders in a niche e-shop platform and invoicing in a local accounting system nobody wrote a connector between. Each tool is fine; the pair has no bridge, so someone retypes every order.

A ready connector assumes a supported pair. When your two tools aren't a supported pair, the "integration" the vendors advertise simply doesn't exist for you — and that's the honest case for a small custom bridge over their APIs.

2. A step needs judgement, not just moving fields​

Who has it: orders that arrive as free-text e-mails or PDF attachments, in no fixed format. No import routine handles them, because there's nothing structured to import — someone reads each one and keys it in.

This is where plain automation stops and AI starts: an agent reads the e-mail or document, extracts what's needed, posts it into the system and escalates only the ones it isn't sure about. It's the same shape as invoice approvals that don't get stuck — capture, route, and keep a human on the exceptions. Two concrete versions of this: orders that arrive as e-mails and delivery notes as PDFs going into your warehouse.

3. The connector exists, but only moves half of what you need​

Who has it: a company using a supported connector that syncs invoices but not the line items, or contacts but not the order history — so the "integration" still leaves a daily manual gap.

Here the fix is usually not to replace the connector but to extend it: a thin bridge that carries the missing data alongside the one you already bought.

Where AI helps — and where it stops​

Plain automation moves data between systems on fixed rules. AI is only worth adding where a step needs to read and decide: understanding a free-text order, classifying an expense, matching a supplier that's spelled three different ways. Everywhere else, a plain API or file bridge is simpler, cheaper and more predictable — and we'll say so.

The line we keep is the same one across our work: AI proposes or drafts, a human confirms anything that matters. No silent bot posting the wrong order into your accounting.

Why this beats a bigger all-in-one system​

The usual pitch is "replace your five tools with one platform." That's expensive, slow, and throws away tools your people already know. Connecting what you have keeps the tools that work and removes only the retyping between them. You don't migrate; you bridge. And you start with one connection you can measure, not a company-wide rollout.

This is the practical side of business process automation: connect the tools, automate the steps, and build custom only where nothing off-the-shelf fits. Where a step needs judgement, our AI solutions overview shows how an agent fits into a controlled process with a human deciding — and AI agents for business covers what those agents actually do.

Who it makes sense for​

• you use several tools that don't share data, and someone retypes between them,
• a ready connector for your exact tools doesn't exist — or only moves part of the data,
• orders, invoices or requests arrive in a form no import routine handles,
• you've been quoted a big all-in-one system to solve what is really a bridging problem.

Want to know which case you're in? Get a free diagnostic — we map how your tools move data today, tell you honestly whether a ready connector already solves it, and if not, show exactly what we'd bridge, the impact and the cost. No obligation, and no build for the sake of building.

Three real problems this solves — and who has them​

1. Corporate housekeeping for a hundred client entities is manual calendar work​

Who has it: a firm that maintains the corporate agenda for ~150 client companies and SPVs. Every change of director, registered seat or share structure means a resolution, a filing and a deadline — multiplied by every entity, forever.

The stakes are statutory: in Slovakia the registry court can fine a company up to €3,310 for not meeting its registration duties, and stale entries surface at the worst moment — mid-transaction, when the counterparty's lawyers run their checks.

How we solve it: the assistant holds the firm's client book and watches the registers for every entity on it. When something changes — or should have changed and didn't — it flags the gap, drafts the resolution and the filing from the firm's own templates, and puts the deadline on the calendar. The paralegal stops being the single point of failure.

2. Beneficial-owner registers are a standing liability, not a one-off form​

Who has it: any firm acting as the oprávnená osoba (authorized person) for clients in the Slovak RPVS — which makes the firm itself responsible for verifying beneficial-owner data, continuously. Fines for incorrect data run up to €1,000,000 (Act No. 315/2016). In Czechia the beneficial-owners register carries fines up to CZK 500,000 — plus suspended voting rights and blocked profit distributions for unregistered owners.

How we solve it: ownership structures on file are checked against the registers on a schedule, changes in the chain (a new shareholder upstream, a merged parent) are detected and flagged, and the verification record the law requires is generated with a full audit trail. The annual "are all our RPVS clients still accurate?" panic becomes a standing, documented process.

3. The official journals publish critical events — and nobody reads them daily​

Who has it: every firm whose clients have counterparties. Liquidations, bankruptcy filings and merger notices are published in the official journals — and creditor deadlines run from publication, not from the moment someone notices. In the Czech insolvency register (ISIR), missing the claim-filing window means the client's receivable is simply gone.

How we solve it: the assistant watches the journals and insolvency registers for every name on the client book — clients and their key counterparties — and when something appears, it summarises what happened, what deadline started running and what the firm's next action is, with the draft ready. The firm calls the client before the client calls the firm.

The figures above are statutory (Act No. 315/2016, Commercial Register Act), not estimates. What the exposure looks like across your own client book — how many entities, how many stale entries, how many unwatched counterparties — is what the free diagnostic maps.

The idea: a loop around the registers​

All three problems share one cause: the registers are the source of truth, but nobody works from them — they work from memory and spreadsheets, and check the registers when it's already urgent.

The goal is not to file anything automatically. The goal is that nothing register-related happens without the firm knowing — and that the paperwork is drafted before anyone had to remember it.

How it works​

• Watchers — the public registers and journals are monitored continuously for every entity and counterparty on the firm's client book; no manual lookups.
• Impact analysis — a detected change is matched to what it means for the client: a filing due, a verification to renew, a deadline started. AI writes the plain-language summary; the rule set behind deadlines is deterministic, not guessed.
• Drafting — resolutions, filings, verification records and client notifications are generated from the firm's own approved templates, pre-filled from register data.
• Human in the loop — nothing is filed or sent without a lawyer's approval. The assistant prepares; the firm decides.
• Audit trail — every check, finding and approval is logged. When a regulator or client asks "how do you monitor this?", the answer is a report, not a shrug.

What gets watched, per source:

Who it makes sense for​

This makes sense for firms where the corporate agenda is real volume, not a side task. Especially if:

• the firm maintains corporate records for dozens of client entities,
• it acts as the authorized person in the beneficial-owners register for clients,
• deadlines live in one person's calendar and inbox,
• counterparty insolvencies have surprised a client before,
• transactions keep getting delayed by stale register entries discovered late.

It pairs naturally with the private firm GPT — one loop knows what the firm wrote, this one knows what the state registered — and with AI agents that carry out the work.

The point isn't automated filings. It's that the registers stop being a place the firm checks when it's urgent — and become a feed the firm acts on before it is.

The payback is concrete: statutory fines that never happen, claim deadlines that never lapse, and the corporate agenda scaling to twice the entities without a second careful paralegal. One client book is enough to prove it.

Want to see it on your own client book? Get a free diagnostic — we map one register agenda and show you exactly what we'd build, the impact and the cost. No obligation.

Three real problems this solves — and who has them​

1. "How did we handle this last time?" takes hours to answer​

Who has it: a corporate firm with ~25 lawyers and twenty years of transactions. The best change-of-control clause the firm ever drafted exists — somewhere, in some deal folder, under some file name. Associates search by asking colleagues; when the partner who remembers leaves, the memory leaves too.

The stakes are measured: professionals expect AI to free up about 5 hours per week — roughly $19,000 of annual value per professional (Thomson Reuters, Future of Professionals 2025), and 92 % of lawyers already use at least one AI tool, with 62 % saving 6–20 % of their week (Wolters Kluwer, Future Ready Lawyer 2026). The gap isn't willingness — it's that generic tools don't know your documents.

How we solve it: the firm's archive — contracts, filings, opinions, templates — is indexed into a private retrieval layer. A lawyer asks in plain language ("our strongest liability cap in an IT outsourcing deal, seller side") and gets the actual passages, with links to the source documents. Onboarding a junior stops meaning "shadow someone for a year."

2. Generic AI doesn't know your documents — and makes things up​

Who has it: any firm whose lawyers quietly paste things into a public chatbot. The answers sound authoritative, cite nothing verifiable — and sometimes cite things that don't exist.

This isn't hypothetical: Stanford researchers found that even purpose-built legal AI tools hallucinated on 17–33 % of queries (Stanford HAI), and courts worldwide keep sanctioning filings with fabricated citations. For a profession where a made-up reference is a career event, "mostly right" is not a product.

How we solve it: the assistant answers only from retrieved documents, every claim carries a citation to the passage it came from, and a deterministic verification step checks each citation against the source before the answer is shown. What can't be supported is flagged as unsupported — not improvised. A lawyer stays in the loop for anything that goes to a client or a court.

3. Client files can't go into someone else's cloud​

Who has it: every firm bound by attorney-client privilege. The fastest way to kill an AI initiative internally is one question from a partner: "so our client's merger documents go where, exactly?"

Under GDPR the firm is the controller and any AI vendor a processor — which requires an Article 28 processor agreement: no training on client data, deletion on request, auditability. After Schrems II, transfers to US providers remain legally fragile. This is not a blocker; it's a design requirement — and a selling point for the firm towards its own clients.

How we solve it: the models and the index run in the EU — or directly on the firm's own infrastructure. Client data is never used to train anything, access follows the firm's matter-level permissions (who can't open the folder can't get the answer either), and every query is logged for audit.

Benchmark figures above are from Thomson Reuters, Wolters Kluwer and Stanford HAI. What your own numbers look like — hours spent searching, onboarding time, exposure — shows up fast once one practice area is on the loop. That's what the free diagnostic maps.

The idea: a loop around the firm's own knowledge​

All three problems share one cause: the firm's knowledge isn't a system, it's a pile. The fix is to wrap a controlled loop around it.

The goal is not to replace lawyers or generate legal advice. The goal is that the firm's accumulated work product becomes searchable, citable and safe to use — and gets better the more the firm works.

How it works​

• Ingest — the document archive is read where it lives (DMS, file server, M365), including OCR of older scans; nothing is copied out of the firm's control.
• Private retrieval — questions are answered from an index of the firm's own documents, respecting matter-level access rights. Public-law research tools stay what they are — a separate, complementary layer.
• Citations, verified — every answer links to the passages it came from, and citations are checked against the source before display. No support → the answer says so.
• Human in the loop — the assistant drafts and finds; lawyers decide. Nothing leaves the firm without a person behind it.
• Compounding — every closed matter enriches the index. The firm's twentieth year of documents finally works as hard as its twentieth lawyer.

What lawyers actually ask it:

Who it makes sense for​

This makes sense for firms where the archive is old enough to be valuable and big enough to be unsearchable. Especially if:

• "ask Peter, he did something similar in 2019" is a real retrieval strategy,
• juniors take months to learn where anything is,
• lawyers already paste text into public chatbots — unofficially,
• clients ask what the firm's AI policy is, and there isn't one,
• confidentiality rules out anything that ships data to a US consumer cloud.

The same applies beyond law — auditors, tax advisors and consultancies have the same pile of past work and the same problem. And it composes with the rest of the loop family: AI agents that do the work and a register-watching corporate assistant.

The point isn't a chatbot with a law degree. It's that the firm's own twenty years of work become an asset you can query — with citations you can trust and confidentiality you can defend.

The payback is concrete: hours of searching handed back every week, juniors productive in weeks instead of months, and the firm's know-how staying home when people don't. One practice area's archive is enough to prove it.

Want to see it on your own documents? Get a free diagnostic — we map one practice area and show you exactly what we'd build, the impact and the cost. No obligation.

What is an AI agent and how is it different from a chatbot?​

An AI agent is software that is given a goal and carries out the steps to reach it on its own: it reads an email or an invoice, looks up context in company systems, prepares a proposal — a posting, a reply, an order — and presents it to a person for approval. A chatbot answers questions; an agent does work. The difference is in steps, tools and accountability for the result.

In practice that means three capabilities a chatbot doesn't have:

• Tools. An agent can reach into other systems — read an email attachment, search the ERP, write a record, send a message. It isn't limited to the text of a conversation.
• Steps. It breaks the task down: first extract the invoice, then find the matching order, then compare amounts, then propose the posting. When a step fails, it can say so — instead of making up a result.
• Guardrails. A well-deployed agent has an explicit definition of what it may do on its own and what always goes through a person. That's not a limitation of capability — it's the precondition for running it in a company.

What can AI agents actually do in a company?​

They work best on repeated processes with a clear input and output: extracting and posting incoming invoices, matching orders with delivery notes, triaging and answering customer requests, watching supplier offers, recurring reporting. In other words, exactly the agenda someone today retypes by hand between email, Excel and the ERP.

Concrete shapes we build:

• Incoming invoices — the agent extracts the PDF from an email or a government data box, finds the matching order, checks the amounts and prepares a record for approval. The full process is described in invoice approvals that don't get stuck.
• Procurement — the agent watches supplier prices, lead times and terms and prepares the groundwork for an order; in detail in the AI buyer.
• Customer requests — a shared mailbox where emails get lost becomes a managed queue with drafted replies; described in the customer request loop.
• Reporting — instead of clicking through five systems by hand, outputs that assemble themselves from real data every morning.

The common denominator: the agent does nothing the company couldn't describe. It does what people do manually today — just consistently, fast, and with an audit trail on every step.

Do you have to replace Pohoda, Money or Helios because of AI?​

No. AI agents are deployed alongside existing systems, not instead of them. Pohoda has XML communication and mServer, Money and Helios offer integration interfaces, ABRA Flexi has a REST API. The agent reads from and writes to them much like a person would — just faster and consistently. The accounting stays where it is, and so do all of the accounting team's habits.

For Czech and Slovak companies this is the key message, because the biggest barrier to adopting AI usually isn't technology — it's the assumption that "to get AI we have to replace the system the company runs on." You don't. A good agent adapts to your environment — government data boxes, the ISDOC invoice format, local document requirements — not the other way around. Replacing an ERP is a multi-year project; deploying an agent on top of the ERP is a matter of weeks.

How do you keep an AI agent under control?​

One rule: the agent proposes, a person approves — until the numbers show that a specific type of step is safe to automate fully. Every proposal carries the evidence it was built from, every action is logged, and outcomes are measured continuously. Autonomy isn't switched on by faith; it's earned gradually, based on data.

This approach has an important side effect: you have numbers from day one. How many documents went through, how many proposals a person corrected, how many minutes the process costs. "Is it worth it?" stops being a feeling — it's a line in a report.

Where do you start so it doesn't become another shelved project?​

With one process that hurts and can be measured. Not "we'll roll out AI across the company," but "incoming invoices from receipt to approval" or "requests from the shared mailbox." A first measurable result within a few weeks is a realistic goal — and only the numbers decide where to extend the loop next.

Signs of a good first process:

• it repeats daily or weekly and eats hours of specific people's time,
• it has a clear input (email, PDF, form) and a clear output (an ERP record, a reply, a report),
• today it runs on manual retyping between systems,
• it can be measured before and after — counts, minutes, error rates.

Who AI agents make sense for​

• the accounting team retypes incoming invoices into Pohoda, Money or Helios by hand,
• sales and support are drowning in a shared email inbox,
• orders, delivery notes and invoicing each live in a different system,
• reporting means half a day of copying into Excel every Monday,
• management wants to start with AI, but not by replacing systems or betting blind.

The goal is not "to have AI." The goal is that a specific process runs faster, cheaper and with an audit trail — and that you see it in numbers, not in a slide deck.

Once agents are running, the next question is whether the whole team actually uses them — see AI adoption you can measure, and our AI solutions overview shows where it fits.

Want to know where an AI agent would help in your company? Get a free diagnostic — we walk through one of your processes and show you exactly what we'd build, the impact it will have and what it costs. No obligation.

What is invoice data extraction?​

Invoice data extraction converts an unstructured invoice document into structured, machine-readable data. Instead of an accountant retyping the supplier name, invoice number, dates, amounts and VAT breakdown, software reads them from the PDF or scan and hands your accounting system a filled-in record — usually with a human confirming the result rather than typing it.

Why it matters is simple arithmetic: keying an invoice by hand takes around ten minutes and manual processing costs roughly €10–15 per invoice, versus under €3 when automated (APQC). For a company with 500 invoices a month, that difference is real money every single month.

How does invoice data extraction work?​

Every serious tool — whatever the marketing says — runs some version of the same five steps:

1. Capture — invoices are collected where they already arrive: a mailbox the tool watches, a drag-and-drop upload, a scanner folder, an API.
2. Pre-processing & classification — the software straightens and cleans scans, detects the language and decides what it's looking at (invoice vs. reminder vs. delivery note).
3. Extraction — the core step: reading header fields (supplier, IDs, dates, totals, bank account) and, in better tools, line items. How this step works is what separates the generations of tools — see the next section.
4. Validation — extracted data is checked against rules: does the VAT math add up? Does the supplier exist in the business register? Does the IBAN match the one on file? Confident results pass; doubtful ones go to a human.
5. Export — clean structured data flows into the accounting system or ERP, typically via API or an import format, with the original document attached.

Template OCR, machine learning, or LLMs — what's actually reading the invoice?​

Three generations of technology are on the market today, often mixed inside one product:

In practice the question isn't "which technology" but "does the tool handle your invoice mix". A company receiving invoices from the same 30 suppliers has a different problem than one receiving them from 800 suppliers in four languages.

How accurate is it — and what does "99 % accuracy" really mean?​

Realistically: modern AI extraction reads 90–99 % of individual fields correctly on decent-quality documents, but that is field accuracy, not invoice accuracy. An invoice with 20 fields at 98 % per-field accuracy still has a ~1 in 3 chance of containing at least one error — which is why every serious deployment keeps a human confirmation step.

The number that actually matters is the straight-through rate: what share of invoices pass with zero human touches. Good deployments reach 60–90 % depending on document quality and supplier mix. Two practical consequences:

• Test on your own sample. Any vendor demo works on clean demo invoices. Send 50 of your real ones — including the ugly scans — and count.
• Validation beats extraction. A tool that flags "VAT doesn't add up, look at this one" is worth more than one that's 1 % more accurate but fails silently.

What does invoice data extraction cost?​

Orientation prices for 2026 — exact numbers vary by tool, volume and contract, but the bands are stable:

What actually drives your price:

• Volume — per-invoice prices drop steeply with scale; most tools sell credit tiers.
• Line items — header-only extraction is cheap; per-line extraction (needed for stock or project costing) often costs extra or a higher tier.
• Integration depth — a CSV export is free; a certified two-way ERP connector may cost more than the extraction itself.
• Validation workflow — approval routing, user roles and audit trails are usually the paid tier, not the OCR.
• Languages and document quality — photographed receipts in three languages are a harder (pricier) problem than clean PDFs in one.

When does it pay off? A five-line calculation​

Take a company with 500 supplier invoices a month, keyed by hand at ~8 minutes each:

• Manual: 500 × 8 min = ~67 hours a month of keying — at ~€18/hour fully loaded, about €1,200 a month, before correction costs.
• Automated: a mid-band tool at €0.20/invoice = €100 a month, plus a quick human confirmation (say 1 min/invoice) = ~8 hours ≈ €150.
• Difference: roughly €950 a month, and the typo-driven corrections (wrong VAT codes, mis-postings) shrink with it.

Below roughly 50–100 invoices a month, a dedicated tool rarely beats "whatever your accounting software includes". Above that, the payback is usually measured in weeks.

Doesn't mandatory e-invoicing make extraction obsolete?​

Not for years, and never completely. Structured e-invoices (Peppol and national formats — Slovakia plans mandatory B2B e-invoicing from January 2027, and the EU's ViDA rules push the same direction for cross-border trade by 2030) remove the need to read those invoices, because the data arrives structured. But three gaps remain: the multi-year transition during which paper and PDF keep coming, foreign suppliers outside the mandate, and everything that isn't a domestic B2B invoice — receipts, contracts, delivery notes, customs documents. Extraction shifts from "everything" to "the messy remainder" — and the messy remainder is exactly where it earns its keep.

How to choose a tool: an 8-point checklist​

1. Does it read your languages — including your suppliers' languages, not just your own?
2. Can you test it on 50 of your real invoices before paying?
3. Does it extract line items, or only header fields — and which do you actually need?
4. Does it validate (VAT math, registry lookups, IBAN changes) or only extract?
5. How does data get into your accounting system — native connector, API, or manual export?
6. What does the human correction screen look like? Your accountant will live in it.
7. Where is data processed and stored — GDPR, retention, and who can read your invoices?
8. What's the price at your volume — including line items and integration, not the headline teaser?

Extraction is step one — approval is where invoices actually get stuck​

Reading the invoice is the easy half. The average invoice still takes 9.2 days to approve (Ardent Partners) — not because extraction is slow, but because the approval lives in e-mails and memory. If that's your bottleneck, we've written a companion piece on building an invoice approval loop that doesn't get stuck, and our AI solutions overview shows where extraction fits into a controlled process with humans deciding. The same document-reading shape shows up beyond invoices — for example orders that arrive as e-mails and delivery notes as PDFs going into your warehouse.

Want to know what extraction would save on your invoice flow — with real numbers instead of vendor claims? Get a free diagnostic — we measure one invoice flow on your own documents and hand you a costed proposal: what we'd build, the impact and the price. If an off-the-shelf tool is the better fit for you, we'll tell you straight.

Three real problems this solves — and who has them​

1. You rolled out AI, but nobody can say what it brings​

Who has it: an IT company with ~100 developers that rolled out an AI coding assistant for everyone. Licenses are paid, the kickoff training happened — and the only adoption signal management has is hallway anecdotes.

Adoption is nearly universal — 78% of organizations now use AI in at least one business function (McKinsey State of AI) — yet more than 80% report no material impact on enterprise earnings from generative AI, and only about 1% of leaders describe their rollout as mature (McKinsey). Tools in, impact invisible.

How we solve it: the assistant's real usage telemetry flows into one place, and a nightly batch turns it into per-developer statistics — prompts, tools and techniques used, activity over time — plus one aggregate picture for the whole company. "Is it worth it?" stops being a feeling: you see who works with it daily, who dropped off after week one, and how usage moves month over month.

2. One training, then a plateau​

Who has it: the same company a quarter later. The enthusiasts sprinted ahead — and most of the team settled into using a powerful agent as a fancy autocomplete. Generic tips ("write better prompts!") help nobody, because every developer is stuck somewhere different.

Self-assessment makes it worse: in a randomized study, experienced developers using AI on familiar codebases estimated they were about 20% faster — while actually being 19% slower (METR). Without measurement, "we're doing great with AI" is exactly the kind of feeling that lies.

How we solve it: every night an AI coach reads each developer's actual usage and writes personal advice — what to try next, which habit to drop, which technique fits the work they actually do. The advice isn't fired blind: a second, independent pass evaluates every piece of advice and weak ones are rewritten before anyone sees them, and yesterday's advice is compared against what actually changed, so the coach keeps learning which recommendations work. Each developer also gets a level — apprentice, journeyman, master — computed from real signals, so progress has a name and a next step.

3. Measurement that doesn't become surveillance​

Who has it: any company where "we'll measure how people use AI" raises an eyebrow — justifiably. Developer trust around AI tooling is already fragile — 46% of developers say they distrust the accuracy of AI output (Stack Overflow Developer Survey 2025) — and telemetry that reads like performance policing kills adoption faster than any missing feature.

How we solve it: privacy is designed in, not promised. The individual sees their own statistics, level and advice. The manager sees aggregate numbers and a coaching direction — never the content of prompts. Secrets (API keys, tokens) are redacted before any AI reads a prompt, and the methodology behind levels and scores is written down and approved by people before it counts. Measurement the team can read about openly is measurement the team will accept.

These are industry benchmark figures (McKinsey, METR, Stack Overflow). What your own adoption actually looks like shows up fast once telemetry is on the loop — that's what the free diagnostic maps.

The idea: a learning loop around AI adoption​

All three problems share one cause: the rollout was an event, not a process. The fix is to wrap a controlled loop around how your team uses AI.

The goal is not to rank people or police prompts. The goal is that every developer gets a personal path to getting better, managers see whether the investment moves, and the system itself learns which advice actually helps.

Nothing heavy runs while people work. Everything is precomputed overnight; during the day developers and managers just open fresh, fast dashboards.

How it works​

• Signals — the AI assistant's telemetry (prompts, tools, techniques, sessions) lands in one store, tied to the user, with a 30-day window.
• Nightly analysis — a batch computes per-developer statistics and a level from real signals, consistently for everyone at once.
• Advice with quality control — AI writes the advice, an independent evaluation scores it, weak advice gets rewritten (generate → evaluate → improve). No raw first drafts reach people.
• Learning from outcomes — yesterday's advice is checked against today's behavior; what worked shapes what's recommended next. The coach improves the same way the team does.
• Human control — the levels methodology is approved by people before it counts, and managers get coaching directions, not transcripts.

Who sees what:

Real numbers from the deployment described above (first weeks): 85 developers with history and 786 pieces of personal advice. Levels settled at 44% apprentices, 39% journeymen and 18% masters. And because the loop compares every piece of advice against the following week's behavior, it already knows which advice lands: the recommendation to try sub-agents was followed by real usage in 78% of measurable cases (21 of 27), broadening the palette of techniques in 30%, and planning mode in 23%. Early correlations, not proof of causation — the point is that the system knows these numbers at all, and tomorrow's advice already leans toward what works.

Who it makes sense for​

This makes sense for companies where an AI tool is already rolled out — or about to be — to dozens of people, so the investment is real. Especially if:

• licenses are bought but usage is a black box,
• one training happened and nothing has changed since,
• power users sprint ahead while the middle of the team stalls,
• management asks "what does AI actually bring us?" and gets anecdotes,
• measuring individuals raises justified privacy concerns.

The point isn't to score people. It's that getting better with AI stops being left to chance — each person knows their next step, and the company finally sees whether the investment moves.

The payback is concrete: the license spend you already committed starts compounding instead of stalling, the middle of the team moves instead of just the enthusiasts, and "is AI worth it?" gets a number instead of a shrug. One team with telemetry is enough to see it.

Measuring adoption goes hand in hand with the agents you actually deploy — see AI agents for business: what they actually do and where to start, and our AI solutions overview shows where both fit.

Want to see how your team actually uses AI? Get a free diagnostic — we map one team's real usage and show you exactly what we'd build, the impact and the cost. No obligation.

But an audit as a one-off PDF report is stale the day it ships — a week later you add a service, AWS ships a new feature, a new CVE lands. So we didn't build a report; we built an auditor that keeps living: every run it measures the same thing deterministically, and between runs it grows its own rule set — proving each new rule before it trusts it.

The problem: gaps you can't see — and an audit that ages before you finish reading it​

Security debt in the cloud isn't one big blunder. It's the sum of small things that never landed on a single screen together — in a state that changes faster than you can review it. That cost concentrates in three problems.

1. The configuration drifts over time and nobody sees the whole of it​

Who has it: any company whose AWS account grew faster than its security practices — root is used "only occasionally" (and has no MFA), the default security group has had SSH and the Docker API open to the internet for years across a hundred network interfaces at once, and disk encryption was never turned on, so 100% of volumes and snapshots are unencrypted.

Each of these is "just a setting" on its own. Together they're an open door: one guessed root password = loss of the whole account; one compromised host = lateral movement through an open Docker API to dozens more. And for an EU company, not encrypting is also a GDPR exposure (Art. 32).

How we solve it: the audit walks service by service across every region and brings all of this onto one page — not a "feeling," but a list with evidence attached to each finding.

2. Without detection and logs, you don't know if you've already been breached​

Who has it: an operation where GuardDuty (threat detection) is off in every region, and VPC flow logs and load-balancer access logs are missing. The servers run, the apps work — but if someone were mining crypto on your instances right now or exfiltrating data, you wouldn't find out.

This is the most insidious part: the absence of a problem looks exactly like safety. As long as nothing happens, nobody misses something they never had.

How we solve it: the audit explicitly checks what you'd actually be able to catch — detection, network and application logs, vulnerability-scan coverage — and where there's a blind spot, it names it as a finding with a concrete fix.

3. A one-off scan is an unranked pile — and it's stale the day it ships​

Who has it: anyone who has ever run a scanner and gotten back 200 "critical" rows with no order — and a month later it's out of date anyway, because both the account and AWS have moved on. An unprioritized list is as useless as no list; and a report that never refreshes is just a snapshot of the past.

How we solve it: every finding gets a severity and an effort estimate and is sorted by benefit/effort (reversible steps first) — and the auditor runs repeatedly, so instead of a snapshot you get a living state that fills itself in between runs (more below).

The idea: a controlled, read-only audit that learns​

The problems share one cause: nobody sees the account's state whole, at once, and continuously. The fix is a controlled auditor — and the same principle holds as for every solution we build: the audit proposes; you decide.

How a single run works​

1. Read-only — the audit runs through read-only access (an SSO role with no write permissions). Nothing is created, changed or deleted. Data itself (e.g. S3 object contents) is never touched — only metadata and configuration are read.
2. A scan across every region — not just the one where the workload runs. "Forgotten" resources in unused regions are a favorite hiding spot for attackers precisely because nobody looks there.
3. Deterministic analysis — findings are computed by ordinary, repeatable code against the CIS AWS Benchmark and AWS Foundational Security Best Practices. Same data → same result, every time. No model "improvising" on the spot.
4. Severity and impact ordering — each finding gets a severity (🔴 critical → 🔵 cleanup) and an effort estimate. The order is by benefit/effort, not alphabetical.
5. A plan, not a list of faults — each finding comes with concrete steps (copy-paste commands), ✅ how to verify and ⚠️ rollback. Reversible steps first.
6. A local dashboard — the output is a local HTML dashboard; nothing is published to the cloud. Accepted risks are edited right there (ADRs, see below).
7. Re-scan and measure — the next run compares the delta (new/resolved) and a falling finding count is a measurable KPI. And the most interesting part happens between runs ⤵

It's not a photo — the auditor teaches itself between runs​

This is the core. The auditor isn't a frozen set of checks: it grows its own rules. On a set cadence (say every 30 days, with no cron at all) a discovery agent runs, uses the current official AWS documentation to find new best practices relevant to your account, and tries to turn them into new checks. But — and this is the whole point — it never just adds one.

The AI writes data, not code​

The key decision everything else rests on: the learning agent never writes code into the audit core. It writes only a rule as data (a declarative statement: "in this file, look at this field; it must have this value"). The measuring stays the same deterministic, tested code.

This separates the "brain" (discovering a new best practice) from the "ruler" (evaluating it). The audit stays repeatable and testable even though an AI extends it. That's the difference between "an audit with AI" (unsettling) and an auditor that proves every rule before it trusts it (trustworthy).

Every new rule is tested first​

A new rule is born with two test fixtures — one that must fail and one that must pass. Before the rule is admitted, a test-gate runs: the bad fixture has to actually fail, the good one has to pass, and the whole test suite has to stay green. Only then is the rule allowed in. On the last run the suite was 17/17.

Better nothing than a wrong rule​

The agent adversarially checks itself — for each candidate it asks: does the documentation really say this? does the check match the shape of our data? could it produce a false "PASS"? If any of that fails, the candidate is thrown out.

In one real learning run the agent considered 4 candidates and rejected all 4 for the right reasons:

• a check already covered by an existing CIS rule (no gain),
• a check that would return a false "pass" on an empty list (false-pass),
• a check that blurred with a collection error (false-positive),
• a check over an untrustworthy raw input.

The result of that run: 0 rules added, 0 noise — and that's the correct behavior. An auditor that would rather add nothing than add an unreliable rule is an auditor you can trust.

Gates that hold even without a human​

Even when a candidate holds up, it must pass three gates: a mandatory citation of authoritative AWS documentation (no source = rejected), add-only (never silently softens an existing rule or severity), and the test-gate above. Every rule therefore carries its provenance — source, doc URL, date.

What can't be safely automated → a proposal for a human​

Sometimes there's a real gap the agent can't safely add on its own (the check is outside the declarative form, or new data has to be collected). Then it commits nothing — it writes a proposal for a human. That's exactly what happened once: the agent discovered that vulnerability scanning for container images and Lambda was turned off, even though the account uses them — but the check didn't fit the declarative form. It wrote a proposal; a human collected the missing data; and the same check then passed the same gates and has been measured automatically ever since.

★ This is the only part left to a human: the agent proposes → a human extends the collection → the rule passes the same machine gates → the audit measures it deterministically from then on.

What triggers a fresh look​

The auditor doesn't look again "just because the calendar says so." A fresh look is triggered by two real changes:

• A service appeared in your account. The auditor works out for itself which services the account actually uses and compares them against what it already checks. When you start using something new — say Cognito or EKS — it flags it as an uncovered service and, on the next learning run, looks up best practices for it and proposes a check.
• AWS itself changed something. The auditor watches AWS "What's New" and Security Bulletins (RSS, over verified TLS), filters them down to your services + security keywords, and takes only what's new since last time. That turns "review once a month" into something changed → look at it now. In a baseline run it pulled dozens of relevant items out of ~170 — including fresh CVEs in services the account actually uses (e.g. an HTTP/2 vulnerability in WAF, a containerd CVE affecting ECS).

Decisions the system remembers (ADR)​

Not every finding is a bug to fix — some are consciously accepted risks. So the auditor stops alarming on them but doesn't forget them, they get a record: an ADR (Architecture/Accepted Decision Record). You record the decision — what you're accepting, why, who approved it, the compensating control, and until when it holds — right in the dashboard. From then on the auditor doesn't show it as an alarm… but once the review date passes, the finding resurfaces on its own for reassessment.

This gives the system three clean layers of trust:

Why read-only — and why you can trust it​

The audit changes nothing in the account. That's not a limitation, it's a feature: you get the full picture of risk without risking anything. You run the remediation commands yourself (or we do it together, with admin access) only once you understand the impact — and we do it reversibly first (a key is deactivated before it's deleted, once you've confirmed nothing broke).

It's the same principle as in all our solutions: the system prepares the work; a person decides and runs it. With security that goes double — nobody wants an "automatic fix" cutting off SSH to production at midnight. That's why the learning itself may only add checks, never turn anything off.

What the audit typically finds​

From a real audit (anonymized) — patterns that recur in almost every account no one has walked through in a long time:

Just as important: an audit should be balanced. The output also includes what's set up well (a central CloudTrail with log validation, locked-down buckets, strong TLS policies, service accounts with least privilege) — so you don't break it during remediation.

What we measure​

Security can be measured — and without measurement "improvement" can't be proven:

Who it's for​

It makes sense for any company on AWS whose account hasn't been systematically reviewed in a while — especially if:

• the account grew fast and security practices couldn't keep up,
• it runs across multiple accounts / via Control Tower and lacks a central overview,
• it handles personal or regulated data (GDPR, customers, healthcare, energy),
• it has no dedicated security team to check it continuously,
• you want a continuous picture of risk — one that doesn't refresh once a year, but grows with the account.

The audit changes nothing on its own. It walks the account read-only, finds and evidences the issues, ranks them by impact, grows its own rules between runs (proving each one first), and hands you a living remediation plan — instead of a PDF that's stale the day it ships.

Want to know where your account stands? Get a free diagnostic — we run a read-only scan of your AWS account and show you the top findings, their severity, and a prioritized remediation plan. We change nothing, you risk nothing. No obligation.

The problem: paper in, invoice out — with a reconciliation step nobody enjoys​

This isn't a "scan to text" problem. The document is a hand-filled form, so the scan is noisy — and the number on the form is rarely the number you bill on. That cost concentrates in three concrete problems.

1. Thousands of noisy sheets, retyped by hand​

Who has it: an organization whose field teams hand-fill work-order sheets across dozens of branches, so a single month's billing means keying thousands of scanned sheets — with no text layer — into an exact spreadsheet structure before anything can be invoiced.

Handwriting makes the scan ambiguous in the worst possible places: a 9 reads as 1 (a quantity of 9.00 vs 1.00), 2026 reads as 2018, an operation code 112 reads as 122. Every one of those becomes a wrong invoice line if a tired person keys it at 11 p.m. on deadline.

How we solve it: the sheets are read by an ensemble of independent vision models, not one — and the system never keys blind. Where the models disagree on an item, a quantity or an operation, that field is marked uncertain rather than guessed.

2. The code on the sheet isn't the code you bill on​

Who has it: any operation where the field form uses one vocabulary and the billing system uses another — the item is written 649 2 on the sheet but stored as 0649_2 in the order list; a job is marked operation 122 on the form but billed under 111 in the order.

Match the two literally and you get near-zero matches — and a person spends the day hand-correcting. This is the single most common silent reason a batch "won't reconcile."

How we solve it: every line is reconciled against the order list — the authoritative source of codes (internal codes, framework order, item, operation, quantity) — using a canonical key that normalizes the mismatch (pads the item code to a fixed width, unifies separators, maps 122 → 111). In one real batch, fixing just the item key lifted matches from 8 of 28 to 22 of 28.

3. The errors hide until they're invoices​

Who has it: an operation billing against capped orders, where booking more quantity than the order allows, or against the wrong item, isn't caught until reconciliation at year-end — when it's expensive to unwind.

How we solve it: the system cross-checks each line against the system of record and the order caps, and flags over-booked orders, quantity mismatches and missing sign-off before they reach the invoice — as exceptions queued for a human, not errors buried in a spreadsheet.

The idea: a controlled reconciliation system​

All three problems share one cause: the data lives on paper and gets reconciled by hand under deadline. The fix is to wrap a controlled system around it — and, as always, the system prepares the work; a person makes the call.

How it works​

1. Extract — every scan is rendered at high resolution and read by several independent vision models. The system finds the boundaries of each sheet itself (a sheet can run to several pages, with sketches and blanks in between) and pulls the header and each work line.
2. Reach consensus — repeating fields (branch, unit, the responsible person, the stamp) are settled by majority vote across the batch: a value seen the same way on several sheets beats a one-off misread.
3. Reconcile against the order list — every line is matched to the authoritative order list on a canonical key, which supplies the correct billing codes and prices and corrects the field-form vocabulary.
4. Cross-check the system of record — where an official record export exists, the system pulls the authoritative quantity, verifies the quantity on the sheet against the system, and checks the order caps.
5. Flag, don't guess — anything uncertain or unmatched is highlighted and written to a control report, with the reason. Nothing ambiguous is silently pushed into the billing file.
6. Build the workbook — the output is the exact structure the operator bills on: an overview sheet (what we know / the result / what's missing), the work list (WL), the order reference, and the cover sheet with totals. Each row carries the source file and page, so any number can be traced back to the original scan.
7. Measure & repeat — next month, you just drop in the new scans; already-processed sheets are skipped and only the new ones are read.

It's also a control on the input documents​

Alongside billing, the system acts as an automatic control on the input documents: it checks every sheet as it arrives, before anything reaches billing. It watches for:

• completeness — missing fields (quantity, item, sheet number),
• the responsible person's signature and stamp — is the sheet even valid, and is that person authorized for this branch,
• consistency with the system of record — do the quantity and item on the sheet match what's in the system,
• order caps — is more booked than the order allows,
• duplicates — the same document scanned twice (or two originals) isn't billed twice: the system keeps the more legible one and lists the other as a duplicate,
• a valid sheet number — it has to match the batch (year, month, branch).

So the output isn't only a billing file — it's also a picture of input quality: which sheets are clean, which are missing a signature, which exceed the order, and which need to go back for completion. The paperwork gets checked at intake, not at year-end.

Two independent safety nets — this is why it's trustworthy​

Hand-filled forms are noisy, so a single read is never trusted. Reliability rests on two independent nets:

• Consensus across documents catches OCR misreads on the fields that repeat.
• Reconciliation against the order list catches the fields that vary (item, operation, quantity) — the order list has the final word.

And a rule that matters more than any model: never fake certainty. A field the system isn't sure about is turned yellow and listed for review — not quietly invented. On a batch of thousands, that turns month-end from retype everything and hope into review only the handful of flagged rows.

The system learns from the human's decisions​

The system doesn't close when it hands over the file — it closes through the person. Every time someone resolves a flagged (yellow) row — confirms that 9.00 should be 1.00, matches an item that wasn't found, or corrects a misread code — the system remembers that decision and applies it itself next time:

• repeated fixes become rules — the same code swap (122 → 111) or item-format quirk isn't asked twice,
• confirmed matches enrich the order list — what a person mapped once, the system maps on its own,
• the share of flagged rows falls month over month — the system absorbs the human's judgment, so there's less to review each time.

So it isn't a one-off retype but a system that gets better with every close — precisely because it leaves the decision to a person and learns from it.

What the output looks like​

The work list is the operator's exact billing structure — here simplified to the columns that matter:

The yellow row is the point: it isn't dropped and it isn't guessed — it's surfaced for a person to resolve in seconds, with the source scan one click away.

What we measure​

A reconciliation system should be measured from day one:

If the first version doesn't collapse the retyping and catch the errors earlier, you know quickly — that's the point of validating on one month first.

Who it's for​

This is not really about any one industry. It makes sense for any operation that runs on hand-filled forms that have to be reconciled against a master list and billed — construction site dockets, field-service tickets, delivery notes, agricultural and subsidy claims, public-sector paperwork. Especially if:

• the forms arrive as noisy scans with no text layer,
• the codes on the form differ from the codes you bill on,
• someone reconciles hundreds or thousands of them by hand at month-end,
• billing is capped by an order or contract, and over-booking is expensive,
• you want AI to do the reading — but a person to keep the final say.

The system doesn't invoice anything on its own. It reads the scans, reconciles every line against the authoritative source, flags what it isn't sure about, and hands a person a billing file plus a short list of exceptions — instead of a thousand forms to retype.

The same read-then-reconcile problem shows up on supplier invoices — our neutral guide to invoice data extraction: how it works and what it costs walks through the invoice version, from capture to validation.

Want to see it on your own paperwork? Get a free diagnostic — we take one real batch of your forms, run it through the system and show you exactly what we'd build, the match rate, and what it saves. No obligation.

The problem we see​

Buying in a smaller company is rarely a real process. It's someone remembering, someone googling, and someone hoping the usual supplier still has it at a decent price — with the scattered long tail of small purchases nobody controls.

That long tail is bigger than it looks: by some estimates, small unmanaged purchases are only about 20% of spend but touch ~80% of suppliers — a tail of buying that quietly eats time and margin. And stock-outs aren't free: the best-run operations lose around 2% of sales to them, while strugglers lose 11–16%.

Three real problems this solves — and who has them​

1. Reordering by gut, noticing too late — the stock-out​

Who has it: a 30-person plastics-component manufacturer where the shift lead reorders regranulate and a few critical additives by eyeballing the racks — and twice this quarter a line idled half a day waiting on a resin that "looked like there was plenty".

Retail out-of-stock sits stubbornly around 8% (8.6% in Europe) and costs roughly 4% of sales, and when an item is out about 31% of shoppers go to another store (Corsten & Gruen). The SMB's own ERP often only carries a static reorder point someone typed in once and never revised — so it either nags constantly or stays silent while real consumption has drifted.

How we solve it: the buyer learns this company's real consumption pace from past orders and invoices, projects when each item crosses its lead-time horizon, and flags what's running low with a suggested quantity before the stock-out — a moving trigger driven by your usage, not a number from 2022. The human still presses buy.

2. Dead stock and over-ordering quietly freezing cash​

Who has it: a family electrical wholesaler with €4M of stock, roughly a third of which never turns — and the owner can't get a loan released because the cash is sitting on shelves as fittings nobody's bought in 14 months.

Overcorrecting for stock-outs, buyers over-order "to be safe", and capital freezes in slow movers. Carrying cost runs 20–30% of inventory value a year (NetSuite), and cutting inventory just 10–15% on a €10M book frees €1–1.5M in working capital.

How we solve it: because the buyer scores items by actual consumption, it suggests right-sized quantities instead of padded safety buffers and surfaces the slow and dead movers it would stop reordering — shrinking the excess tier directly, with the human keeping the call on liquidation.

3. Hours googling suppliers, buying from whoever's easiest, reliability stuck in one head​

Who has it: a 25-person electrical contractor whose stores person spends a morning a week tracking down a non-stock breaker and a cable run — calling three wholesalers, and still occasionally ordering the wrong rating.

37% of procurement teams want to spend less time sourcing simple purchases, and the long tail is where margin leaks: the ~20% of spend spread across ~80% of suppliers gets no price scrutiny, yet actively managing it yields around 7% savings (Hackett Group). Worse, supplier reliability — who's on time, who slips, who sent the wrong item last spring — lives only in the buyer's head and walks out when they're sick or leave.

How we solve it: for each item the buyer searches and scores suppliers on price, availability and reliability — from your own order history — and proposes a "what to reorder and from whom" shortlist in seconds. Every outcome you report (late delivery, wrong item, good price) feeds a reliability score, turning tribal knowledge into durable data. It proposes; you buy.

These are widely-cited industry benchmarks, linked to their sources above. The real numbers for your stock and orders come out of the free diagnostic.

The idea: a buyer that proposes — you decide​

All three problems share one root: nobody is watching your real consumption and supplier history, so buying happens from memory and a search engine. The buyer does that watching for you.

The goal isn't to hand purchasing over to a bot. It's a controlled loop where a buyer does the watching and the legwork, and a human stays firmly in control of every order.

It does not buy anything on its own. It prepares the decision — what's missing and where to get it — and the responsible person places the order.

How it works​

1. Learn what you buy — the buyer picks up your recurring purchases from past orders, invoices and your product or material list.
2. Watch the stock — connected to your inventory, it tracks levels and the pace you consume things, so it knows when something is about to run out.
3. Flag what's running low — instead of a gut check, you get a clear "about to run out" list with suggested quantities, before it becomes a stock-out.
4. Find & score suppliers — for each item it searches options, compares price and availability, and rates suppliers on reliability — delivery time, price stability, past experience.
5. You decide & buy — you review the shortlist, pick, and place the order. Nothing is ordered without you.
6. Feedback — you tell it how it went (supplier delivered late, wrong item, great price). That feedback tunes the next recommendation.

Where exactly AI helps — and where it stops​

AI is useful here because buying is messy and repetitive at the same time. It helps with:

• recognising your recurring purchases and predicting when you'll need them again,
• spotting what's about to run out before a person would,
• searching and comparing suppliers across the web and your own history,
• scoring supplier reliability from delivery, price and past orders,
• drafting the "what to reorder and from whom" list.

But the line is deliberate: AI proposes, the human buys. It doesn't spend your money, sign off on a supplier or commit an order. That stays a human decision — which also means no runaway bot ordering the wrong thing.

Two jobs, one loop​

The same buyer covers two needs, depending on the company:

Most companies want a bit of both — and the loop handles both from the same picture of what you buy.

How it gets sharper​

Every order teaches it something, because you close the loop with feedback. Over time:

• reorder timing fits your real consumption, not a flat rule,
• supplier scores reflect who actually delivered well for you,
• the long tail of scattered buying gets visible and controllable,
• recommendations stop being generic and start matching how you really buy.

What we measure​

A buyer loop should be measured from the first version.

Why it works better than googling and gut reorders​

A search engine can find a supplier. It can't watch your stock, remember who let you down, or learn what you reorder. A controlled buyer loop gives you:

• one "what's running low" list instead of noticing too late,
• rated suppliers instead of whoever came up first,
• buying decisions backed by your own history,
• the scattered long tail under control,
• a human firmly in charge of every order.

You don't need a procurement department or an enterprise system to start. One category of what you buy, your stock data and your order history is enough to show whether the loop is worth scaling.

Who it makes sense for​

This makes sense for companies that buy the same kinds of things again and again, especially with a warehouse. Particularly if:

• you hold stock and stock-outs (or dead stock) hurt,
• people spend real time hunting the internet for suppliers,
• reordering happens by gut and gets noticed too late,
• supplier reliability isn't tracked anywhere,
• lots of small purchases happen with no real overview.

The point isn't to take buying out of human hands. It's to do the watching and the legwork — what's running low, where to buy it, who's reliable — so the person who decides can decide fast and well.

The payback is concrete: fewer stock-outs that cost you sales, less cash frozen in dead stock, and the scattered long tail bought from the best option instead of the easiest — with a human firmly in charge of every order. One category of what you buy is enough to prove it.

The buyer is one shape of an AI agent among several — see AI agents for business: what they actually do and where to start, and our AI solutions overview shows where it fits.

Want to see it on your own stock and orders? Get a free diagnostic — we map one category of what you buy and show you exactly what we'd build, the impact and the cost. No obligation.

The problem we see​

Below a certain size, "controlling" usually means one capable person — the owner, an accountant or a part-time CFO — rebuilding the same spreadsheets every month. The numbers exist, but they're scattered across the accounting system, the bank, invoicing, a CRM and a few Excel files. Someone exports them, pastes them together, fixes what doesn't match, and a week into the new month finally has last month's picture.

Studies of finance teams put roughly 75% of their time on gathering and cleaning data, and only about 25% on actual analysis. In a small company without a controller, that ratio is even worse — the person who should be interpreting the numbers spends their time assembling them.

Three real problems this solves — and who has them​

1. No live cash view — the founder rebuilds a cash spreadsheet every month-end​

Who has it: a €6M e-commerce brand where the founder rebuilds a cash spreadsheet every month-end, juggling supplier prepayments against marketplace payouts, and only notices a squeeze when a big stock order and a VAT payment land in the same week.

Cash-flow problems are the most-cited cause of small-business failure — the widely-quoted ~82% figure (U.S. Bank via SCORE) — and the 2024 Fed Small Business Credit Survey found 44% of small firms missed a payment because of a cash-flow problem in the prior year. Running blind on cash isn't an inconvenience; it's the top correlate of going under.

How we solve it: it connects bank, invoicing, AP and ERP, validates the feeds and keeps an always-current cash position plus a rolling forward forecast — replacing the monthly copy-paste rebuild, with AI explaining in plain language why cash moved and when the next dip is coming. Nothing is auto-paid; a human decides.

2. Last month's numbers arrive a week late, so decisions run on stale data​

Who has it: a €12M services firm where the external accountant delivers last month's P&L on the 10th–12th — by which point the MD has already committed to a new hire and a fleet lease without knowing the previous month's margin actually slipped.

For SMBs the month-end close routinely takes 6–10 business days, and 59% take six or more (Numeric). By the time the picture is "ready" the team is a third of the way into the next month, looking backward instead of ahead.

How we solve it: because it ingests and validates source data continuously, it produces a current-month P&L and margin picture that doesn't wait for a formal close, and AI narrates what changed versus last month and versus forecast — opening the decision window days earlier.

3. Margins by product/project/customer are unknown, and slow payers aren't flagged​

Who has it: a €10M project firm with a healthy headline margin where two of its five biggest projects are quietly run at a loss and the rest carry them — so the founder keeps selling more of the loss-makers because they look like growth.

A single blended margin hides the money-losers. Meanwhile late payment is a structural drain in Europe: the EU Payment Observatory reports average payment periods exceeded 60 days in 2024 with more than half of companies reporting resulting difficulties, and estimates EU SMEs could unlock over €100 billion a year if paid on time. Without segment margins and a forecast, both the loss-making project and the customer drifting from net-30 to net-65 stay invisible until cash is already tight.

How we solve it: it tags revenue and cost to product, project and customer for true segment margins, forecasts cash and margins on a rolling basis, and flags anomalies early — a slipping margin, a customer's DSO creeping up — and the forecast gets sharper every month by comparing what it predicted to what actually happened.

The Europe-specific figures (EU Payment Observatory) are the most authoritative here; the "82%" cash-flow stat is widely cited but a hardened popularization. The real numbers for your business come out of the free diagnostic.

The idea: a controlling loop that gets sharper every month​

All three problems share one root: the financial picture is rebuilt by hand, so it's late, blurry and trapped with one person. Make it continuous and the rest follows.

Controlling shouldn't be a spreadsheet rebuilt from scratch each month. It should be a loop that runs continuously, keeps a human in control, and gets sharper from the gap between what it predicted and what actually happened.

The goal isn't another dashboard. It's a controlling process that gets sharper the longer it runs.

How it works​

1. Connect the sources — accounting/ERP, bank statements, invoicing, CRM and the few spreadsheets that already hold the truth.
2. Validate before showing — the system checks missing entries, duplicates, unusual movements and mismatches between sources, instead of pushing bad numbers into a report.
3. Build the picture — a clean, current view of cash, P&L, and margins by product, project or customer — without the monthly copy-paste.
4. Explain & forecast — AI summarizes what changed in plain language and projects cash and margins forward, with links back to the source numbers.
5. Human decides — the owner or finance lead reviews, asks questions and makes the call. Nothing is auto-posted or auto-paid.
6. Measure & improve — the loop compares each forecast to what actually happened and adjusts, so next month's projection is better than last month's.

Where exactly AI helps​

AI is not the accounting engine. The numbers come from your real ledgers and clear rules. AI helps around the parts that normally eat a controller's week:

• pulling messy data from different systems into one consistent picture,
• explaining why a number moved (not just that it did),
• forecasting cash and margins, and updating the forecast as reality comes in,
• flagging anomalies worth checking — a margin slipping, a customer paying slower,
• answering plain-language questions over the numbers ("why is cash lower than last month?"),
• turning the picture into management notes a non-finance owner can act on.

For example, AI shouldn't invent a forecast and present it as fact. But it can say:

"Cash is projected €40k tighter by month-end than last month, mainly because two large customers shifted from 30- to 45-day payment, and material costs rose 6%. At the current run-rate you stay positive, but a delayed payment from your top customer would put you under your buffer."

That turns a spreadsheet into a decision.

What "gets sharper every month" actually means​

This is the part a static dashboard never does. Each cycle, the loop writes down what it expected — cash at month-end, margin on a project, when a customer would pay — and then compares it to what actually happened.

Over a few months that feedback compounds:

• forecasts stop being a straight-line guess and start reflecting your seasonality and payment behaviour,
• the loop comes to recognise which customers really pay late versus which just look late,
• it gets better at telling which cost movements are noise and which are a trend,
• the explanations sharpen, because the system knows which signals mattered last time.

The controller doesn't start from zero every month. The loop carries forward what it worked out before.

What we measure​

A controlling loop should be measured from the first version — including the cost of controlling itself.

Why it works better than a month-end Excel​

A spreadsheet can hold the numbers. It can't run the process, and it never improves on its own. A controlling loop gives you:

• a current picture instead of one that's a week late,
• a forecast that improves instead of a static guess,
• early warnings instead of surprises at month-end,
• margins you can see instead of argue about,
• controlling that doesn't break when one person is on holiday,
• time spent deciding, not assembling.

You don't need a full FP&A team or an enterprise system to start. One company, its real ledgers and bank feed, and one recurring controlling cycle is enough to show whether the loop is worth scaling.

Who it makes sense for​

This makes sense for companies that have outgrown "the accountant sends a report" but can't yet justify a full controlling department. Especially if:

• there's no dedicated controller and finance leans on one person,
• the cash position is never quite clear in real time,
• decisions are made on last month's numbers, or on gut feeling,
• margins by product, project or customer are fuzzy,
• the owner or part-time CFO spends more time building reports than using them.

Good controlling shouldn't just tell you what happened last month. It should tell you what's coming, flag what needs attention — and get better at both every time the month closes.

The payback is concrete: a current cash position instead of a guess, decisions made days earlier on numbers you trust, and the money-losing project or slow-paying customer caught before it hurts — for a fraction of a controller's cost, with a human always in the decision seat. One company's ledgers and bank feed are enough to prove it.

Controlling is only as good as the reporting under it — see why manual reporting isn't business intelligence, and our AI solutions overview shows where a controlling loop fits.

Want to see it on your own numbers? Get a free diagnostic — we map your controlling on one company and show you exactly what we'd build, the impact and the cost. No obligation.

Many companies do not have a support problem. They have an intake problem — and inboxes were never designed to manage work.

Three real problems this solves — and who has them​

1. Slow first response quietly kills inbound leads​

Who has it: a 25-person B2B services agency where the website "Contact us" form emails a generic inbox the office manager checks twice a day — so a hot lead for a €40k engagement sits nine hours before anyone replies.

Responding within five minutes makes you about 21× more likely to qualify a lead than waiting 30 minutes (MIT/InsideSales), yet the average company takes 42–47 hours to respond to a web lead and 78% of buyers purchase from the vendor that responds first (HBR). The lead isn't visibly lost — it just goes cold while a competitor answers in ten minutes.

How we solve it: AI classifies a request the moment it arrives, flags it as a sales inquiry with urgency/VIP, routes it to an owner immediately and drafts a reply from past winning answers — so a human approves and sends in seconds instead of hours.

2. The shared inbox where things fall through the cracks​

Who has it: a 30-person B2B SaaS where support@ is a shared Gmail three people "kind of" watch — nobody is sure who answered the angry customer yesterday, and the founder learns about a churned account from a Friday LinkedIn post.

Over half of teams on a shared inbox report missed or delayed responses caused by confusion over who owns what. Two people reply to the same customer with contradictory answers; urgent messages sit unread; nobody can say what's actually open right now.

How we solve it: it sits on top of the inbox you already use and turns every request into a tracked item with exactly one owner, a status and a clear "what's open" board — so collisions become impossible and managers finally see the backlog, without customers changing the address they write to.

3. The same answer rewritten for the tenth time, with no prioritization​

Who has it: a 50-person e-commerce brand whose reps answer "where is my order?" and "how do I return this?" a hundred times a day, each writing their own version — while a churning enterprise complaint sits behind 60 routine emails.

Roughly 60–80% of incoming requests are repeats of the same handful of questions, and customers leave fast and quietly: 57–72% switch to a competitor after one bad experience, and 56% never even tell you (Qualtrics). Skilled people retype near-identical answers all day, and the urgent-but-quiet request rots until it explodes.

How we solve it: AI drafts each reply from past approved answers so agents edit instead of write from zero, prioritizes on intake (urgency, SLA risk, VIP sender) so the right requests surface first, and measures the repeats — telling you which eight questions are 40% of your volume and should become an FAQ or automation.

These are widely-cited industry benchmarks (MIT, HBR, Qualtrics). The real response-time and repeat-question numbers for your intake come out of the free diagnostic.

The idea: a customer request loop​

All three problems share one root: the inbox receives work but can't manage it — no ownership, no priority, no memory. A controlled loop adds exactly those.

The goal is to build a controlled loop around incoming requests. Every message is captured, classified, prioritized and assigned. The system can draft a response or suggest the next step, but a human approves what goes out.

This is not an autonomous customer support bot. It is a controlled workflow that helps the team respond faster and learn from repeated requests.

How it works​

1. Capture — collect requests from the channels you already use: mailbox, website form, chat export, CRM notes or shared folders.
2. Classify — identify the type of request: support, sales, billing, complaint, document request, technical issue, internal handoff.
3. Prioritize — detect urgency, customer importance, SLA risk or missing information.
4. Assign — route the request to the right person or team with the context attached.
5. Draft — AI prepares a suggested reply or next step using your existing knowledge and previous answers.
6. Approve — the human reviews, edits and sends. Nothing leaves without approval unless you later explicitly allow a low-risk category.
7. Measure — the loop tracks response time, backlog, repeated questions and unresolved categories.

Where exactly AI helps​

AI is useful because customer requests are unstructured. People do not write in perfect forms. They forward email chains, describe issues vaguely, attach documents or ask three things at once.

AI helps with:

• reading messy messages,
• detecting the intent,
• summarizing long threads,
• extracting missing fields,
• suggesting the right owner,
• drafting a response,
• grouping repeated questions.

But the critical rule stays simple: AI prepares, people decide. That makes the system useful without creating the risk of an uncontrolled chatbot speaking for the company.

What the request queue looks like​

A first working version can start as a simple queue. The value is not only faster replies — it's that the team sees the work clearly.

What we measure​

A request loop should be measured from the first version.

Over time, the loop does not only handle requests. It reveals where the business process itself needs to improve.

Why it works better than a shared inbox​

A shared inbox can receive work. It cannot manage it well. A controlled request loop gives you:

• one queue instead of scattered channels,
• clear ownership,
• priority instead of oldest-first chaos,
• suggested responses instead of repeated writing,
• human approval before anything is sent,
• measurement of what keeps coming back.

Most companies do not need a huge customer support platform to start. They need one controlled intake process that makes work visible.

Where the improvement loop appears​

The real value comes after the first few weeks. The system starts showing patterns:

• "These five questions repeat every week."
• "Billing requests wait longest."
• "Sales requests often miss company size."
• "Support needs better source material for this topic."
• "This request type should become an automated workflow."

That is the difference between automation and improvement. Automation helps the team process work faster. An improvement loop helps the company understand what should change next.

Who it makes sense for​

This is useful for companies where customer or internal requests arrive through many channels and the team still relies on manual sorting. Especially if:

• a shared inbox is overloaded,
• response times are inconsistent,
• requests are forwarded between people,
• the same answers are written repeatedly,
• customers ask for status updates,
• managers do not have a clear view of backlog.

The inbox can receive work, but it can't manage it. A controlled loop makes the work visible, prepares the response and keeps a human in control of what goes out.

The payback is concrete: faster first response that wins more of the deals you already attract, fewer customers lost in silence, and hours of repeated answers turned into reusable replies and FAQs. One intake channel is enough to prove it.

The reusable replies and FAQs this produces are what feeds A company wiki that fills itself — from calls, emails and team output, and our AI solutions overview shows where both fit.

Want to see it on your own inbox or request flow? Get a free diagnostic — we map one request process and show you exactly what we'd build, the impact and the cost. No obligation.

Three real problems this solves — and who has them​

1. The "Monday morning copy-paste" eats the time that should go to thinking​

Who has it: a 200-person distributor where the weekly sales-and-stock report is one ops manager's entire Monday morning — export from the ERP, paste into the master Excel, reconcile against the CRM, send it round by 11am.

Finance and analyst teams spend only about a quarter of their time on actual analysis — the rest goes to gathering and processing data (AFP/APQC), and 75% of finance teams spend 5–6+ hours a week just recreating reports — up to 300 hours a year (insightsoftware). The analysis ("why did the North region drop?") gets the last 20 minutes, or gets skipped.

How we solve it: the report assembles itself from ERP/CRM/Excel on a schedule with zero copy-paste, and AI has already explained what changed — so Monday morning goes from four hours of plumbing to ten minutes of review.

2. "Spreadsheet hell" — nobody fully trusts the number​

Who has it: a mid-market manufacturer whose monthly margin report is a 14-tab workbook only the controller really understands — last quarter a single wrong lookup overstated gross margin and led to a mispriced product line, caught two months later.

Studies of operational spreadsheets find around 88–94% contain at least one error (Panko). A dragged formula, a hardcoded cell, a duplicate row from a double-export — and the number is silently wrong, because checking is the job nobody has time for.

How we solve it: before generating anything, the system validates the data — flags missing values, duplicate rows and mismatches between sources (e.g. ERP revenue ≠ CRM closed-won) — so the report ships with its exceptions pre-flagged instead of "here's a number, trust it".

3. Departments argue about whose numbers are right​

Who has it: a 350-person retailer where the weekly trading meeting stalls because the e-commerce dashboard, the finance spreadsheet and the buying team's report each show a different sales total — so decisions get deferred "until we agree on the number".

Only about a third of executives trust the analytics generated from their own operations (KPMG/Forrester). The data exists — in CRM, ERP, the support tool and three private spreadsheets — but the versions never agree, so every meeting opens with a fight about which number instead of what to do.

How we solve it: one controlled report, fed from all sources with cross-source reconciliation built in and links back to source rows, so discrepancies are resolved in the report. The meeting starts from an agreed number — a single source of truth for one report, without boiling the ocean.

These are survey-based industry benchmarks (AFP/APQC, insightsoftware, Panko, KPMG). The real time and error numbers for your report come out of the free diagnostic.

The idea: reporting as an improvement loop​

All three problems come from the same place: the report is assembled by hand, so it's slow, unverified and owned by one person. Automate the assembly and the rest follows.

A good report should not be a static document. It should be part of a loop. The system collects the data, validates it, highlights changes, explains what needs attention and tracks whether action was taken.

The goal is not to create another dashboard nobody opens. The goal is to make reporting useful for decisions.

How it works​

1. Map the report — we start with one recurring report and identify its sources, owners, formulas and the decisions it supports.
2. Collect data automatically — data is pulled from exports, spreadsheets, ERP, CRM, support tools, databases or emails.
3. Validate before showing — the system checks missing values, duplicates, unusual changes and mismatches between sources.
4. Generate the report — the first version prepares a clean report or dashboard with the key numbers and changes.
5. Explain what changed — AI summarizes important movements in plain language, with links back to the source data.
6. Track decisions — the loop records what people decided based on the report, so the report becomes part of improvement, not just observation.

Where exactly AI helps​

AI is not the reporting engine. The numbers must come from reliable data and clear calculations. AI helps around the messy parts:

• explaining why a number changed,
• summarizing exceptions,
• turning raw report data into management notes,
• detecting anomalies worth checking,
• answering questions over the report,
• helping non-technical users understand what they are seeing.

For example, AI should not invent revenue. But it can say:

"Revenue is up compared to last week mainly because three large orders moved from pending to confirmed. Two regions are still below target, and support backlog increased by 18% after the new release."

That is useful because it turns a table into a decision prompt.

What we measure​

A reporting loop should be measured from the first version — including the cost of reporting itself.

Why it works better than a spreadsheet​

A spreadsheet can hold numbers. It cannot manage the reporting process. A controlled reporting loop gives you:

• one validated source instead of competing versions,
• explanations instead of raw tables,
• early warnings instead of surprises,
• a record of decisions instead of forgotten context,
• measurement of reporting itself, not just the business.

You do not need a full BI platform to start. One recurring report, collected and validated automatically, is enough to show whether the loop is worth scaling.

Who it makes sense for​

This makes sense for companies that already depend on recurring reports but still prepare them by hand. Especially if:

• the same numbers are copied between systems every week,
• reports are late or owned by a single person,
• departments argue about which figures are correct,
• the report shows history but never points to what needs attention,
• you want to use your data but a full BI project feels too big to start.

A report should not just tell you what happened. It should help you decide what to improve next — and then show whether the decision worked.

The payback is concrete: the hours of weekly copy-paste handed back, decisions made on numbers people actually trust, and problems spotted in time to act instead of explained after the fact. One recurring report is enough to prove it.

Reporting that learns is one step from controlling that forecasts — see financial controlling that gets sharper every month, and our AI solutions overview shows where both fit into a controlled process.

Want to see it on your own recurring report? Get a free diagnostic — we map one report and show you exactly what we'd build, the impact and the cost. No obligation.

Three real problems this solves — and who has them​

1. Nobody can say what's waiting, who owns it, or how old it is​

Who has it: a 140-person manufacturer processing ~1,800 supplier invoices a month across three approvers, where invoices land in a shared mailbox and a junior accountant forwards each one by hand.

The average invoice takes 9.2 days to approve — 17.4 days for laggards versus 3.1 for best-in-class teams (Ardent Partners). At month-end, a few hundred invoices are "somewhere in email" and the CFO can't tell finance what's still unbooked.

How we solve it: every invoice — mailbox, upload, portal, scanned PDF — lands in one live queue with owner, age and status visible at a glance, and routing happens automatically by supplier, PO, amount or cost center. "Where is invoice X?" becomes a one-click answer.

2. Every invoice keyed by hand — and the typos surface later as payment errors​

Who has it: a 90-person 3PL where two clerks key ~1,200 invoices a month at roughly ten minutes each — about 200 person-hours a month — and recurring VAT-code slips trigger quarterly corrections.

Manual processing costs roughly €10–15 per invoice versus under €3 when automated (APQC), and the typos resurface downstream as mis-postings and wrong VAT that cost more to unwind than the original entry.

How we solve it: AI extracts and validates the fields — supplier, amount, due date, PO, VAT, line items — and proposes a populated record the human confirms rather than types. It flags missing or suspicious data instead of silently pushing it forward, without replacing your accounting system.

3. Duplicate payments and supplier-impersonation fraud leak real cash​

Who has it: a mid-market retailer with ~2,500 invoices a month across many small suppliers with inconsistent invoice numbering — and no second-approver rule when a supplier's bank details "change".

Even top performers lose ~0.8% of disbursements to duplicate or erroneous payments, and laggards ~2% (APQC). Business email compromise — the fake "new bank account" email — drove $2.77 billion in reported losses in 2024 alone (FBI IC3), and a single such payment is often an unrecoverable five-figure wire.

How we solve it: duplicate detection runs at intake — fuzzy-matching supplier, amount, date and invoice number before anything reaches an approver — and anomalies like changed bank details or a new supplier are flagged and routed to a human with a full audit trail. The exception can't silently slip through, because it's queued, not buried in an inbox.

These are industry-benchmark figures (Ardent Partners, APQC, FBI IC3). The real numbers for your AP show up fast once one invoice flow is on the loop — that's what the free diagnostic measures.

The idea: an invoice approval loop​

All three problems share one cause: invoices live in an inbox instead of a controlled process. The fix is to wrap one around them.

The goal is not to replace your accounting system. The goal is to build a controlled loop around one clear process: invoice intake and approval.

The system captures incoming invoices, extracts the important data, suggests the right approval path and keeps a live queue of what needs attention. Nothing is approved behind anyone's back — the system prepares the work, people make the decision.

How it works​

1. Capture — invoices are collected from the places where they already arrive: mailbox, upload folder, supplier portal or scanned PDFs.
2. Extract & validate — the system reads supplier name, amount, due date, PO number, VAT data and line items. It flags missing or suspicious information instead of silently pushing bad data forward.
3. Route — based on supplier, amount, department or project, the invoice is sent to the right approver.
4. Approve or reject — the approver sees the invoice, the extracted fields and the reason for routing. They approve, reject or ask for clarification.
5. Track — accounting sees what is waiting, who owns it and how long it has been open.
6. Improve — the loop shows where invoices get stuck, which suppliers create problems and which approval paths are too slow.

Where exactly AI helps​

AI is useful here because invoices and approvals are messy. Suppliers use different formats. Some invoices arrive as PDFs, some as scans, some inside long email threads. People write short comments like "OK for project X" or "ask Peter first" that need context.

AI helps with:

• reading invoice documents,
• extracting structured fields,
• recognizing supplier and project context,
• suggesting the likely approver,
• summarizing exceptions in plain language,
• detecting missing or inconsistent data.

But the approval itself stays with the human. AI proposes. The responsible person decides.

What the approval queue looks like​

The first working version can be very simple: a queue of invoices waiting for action. The value is not the table itself — it's that the process becomes visible.

What we measure​

A good invoice approval loop should be measured from the beginning.

If the first version does not reduce waiting time or manual follow-up, we know quickly. That is the point of validating on one process first.

Why it works better than email​

Email can move an invoice. It cannot manage the process. A controlled approval loop gives you:

• one queue instead of scattered inboxes,
• clear ownership instead of "who has this?",
• approval history instead of buried replies,
• exception handling instead of silent mistakes,
• measurement instead of guessing.

The system does not need to be big to be useful. Even a first version that handles one mailbox, one approval rule and one accounting handoff can show whether the process is worth scaling.

Who it makes sense for​

This makes sense for companies where invoices are frequent enough that delays and follow-ups have become normal. Especially if:

• invoices arrive in multiple formats,
• approvals depend on different people,
• accounting often has to chase missing decisions,
• duplicate or incorrect invoices are a risk,
• the team wants automation but cannot replace the accounting system.

The system does not approve anything on its own. It makes the process visible, prepares the work and measures where it gets stuck — so the people who decide can decide faster.

The payback is direct: cost per invoice down from the manual €10–15 band toward a few euros, approval time from days toward best-in-class, and duplicate and fraudulent payments stopped before the money leaves — on top of early-payment discounts you can finally catch. One mailbox is enough to prove it.

Getting the invoice read is the step before this one — if capture is your bottleneck, see our neutral guide to invoice data extraction: how it works and what it costs, and our AI solutions overview shows where approval fits into a controlled process.

Want to see it on your own approval process? Get a free diagnostic — we map one invoice flow and show you exactly what we'd build, the impact and the cost. No obligation.

The problem with classic wikis​

Companies don't fail at wikis because the tool is bad. They fail because keeping it up to date is manual work nobody owns:

• the knowledge exists, but in a call recording no one re-listens to,
• a decision was made in an email thread that never made it to the wiki,
• the one page that mattered is six months out of date and quietly wrong.

So people stop trusting the wiki, stop using it, and the knowledge scatters again.

Three real problems this solves — and who has them​

1. People burn one to two hours a day just hunting for information​

Who has it: a 60-person logistics brokerage where the operating knowledge — carrier quirks, customs edge-cases, who-to-call — lives in email threads and phone calls.

Knowledge workers spend on average ~1.8 hours a day (around 9 hours a week) searching for and gathering information (McKinsey), and 47% of digital workers struggle to find what they need to do their job, juggling 11 different apps on average (Gartner, 2023). The answer usually exists — in a recording nobody re-listens to, a thread nobody linked — it just costs more to find than to redo.

How we solve it: the wiki fills itself from the calls, emails and tickets the team already produces, into interlinked pages with a link to the exact source — so the answer was captured automatically and people trust it instead of re-asking.

2. When an expert leaves, a chunk of "how we do it" walks out the door​

Who has it: a 40-person engineering consultancy where two principals hold the deployment know-how and the "why we do it this way" for the firm's flagship methodology — and one just announced retirement.

Around 42% of institutional knowledge is unique to the individual who holds it (Panopto) — so when they leave, the team literally can't do that part of the job. Replacing the person costs 50–200% of their salary and a successor takes 6–9 months to ramp, because the docs were never written: experts are too busy being experts.

How we solve it: the wiki has been capturing the expert's calls, emails and decisions all along, with sources — so the departure becomes a review-and-approve exercise instead of a frantic archaeology dig.

3. New hires ramp slowly and the same questions get answered again and again​

Who has it: a 90-person B2B software company hiring two to three reps a quarter, where top reps lose hours every week mentoring instead of selling.

A new hire can't be productive until they've absorbed processes, pricing edge-cases and customer context that live in people's heads — so they interrupt the most expensive people, repeatedly. Sales ramp alone averages five-plus months, and across support, 60–70% of incoming questions are repeats of something already answered.

How we solve it: the wiki auto-builds the onboarding corpus from real winning calls and resolved tickets, answers questions on demand with citations so people self-serve, and flags its own stale pages so the content never silently rots.

The strongest figures here are survey-based industry benchmarks (McKinsey, Gartner, Panopto). The real number for your team is what we measure in the free diagnostic.

The idea: the wiki fills itself​

Search time, lost experts, slow onboarding — all three trace to one thing: keeping knowledge current is manual work nobody owns. So we remove the manual step.

Instead of asking people to write documentation, the system listens to what they already produce — calls, emails, meeting notes, ticket resolutions — and turns it into structured, interlinked wiki pages. People only review and approve.

How it works​

1. Capture — connect the sources you already use: call transcription, a shared mailbox, meeting notes, your ticketing tool.
2. Extract & structure — AI pulls out decisions, facts, how-tos and FAQs, and links them to existing pages instead of creating duplicates.
3. Draft, don't publish — it proposes a new page or an update, always with a link to the source (which call, which email).
4. Human approves — someone confirms or edits in one click. Nothing goes live unreviewed.
5. Stay honest — the system flags pages that contradict newer information or look out of date, instead of letting them rot.

Why AI changes the equation​

Classic wikis needed a person to write every page. The reason this is newly possible is the same one we wrote about in where AI makes sense: AI can read messy, unstructured input (a rambling call, a long email chain) and turn it into something structured — and it can answer questions over it with citations, the RAG pattern.

But the value isn't "AI writes your docs". It's that the wiki stops being a chore:

Where it pays off​

The biggest impact is in teams where knowledge is created in conversations, not documents: sales and customer calls, support, consulting, operations. If your important decisions live in inboxes and recordings, this is for you.

The point isn't a prettier wiki. It's that the knowledge your team already creates stops disappearing — and the wiki earns back the trust to actually get used.

The return is concrete: hours of searching handed back to the team, new hires productive in weeks instead of months, and the expert's know-how safe before they ever hand in their notice. One captured knowledge area is enough to see it.

Two neighbours turn the same raw input into something you can query: From inbox chaos to a controlled customer request loop and A private GPT for your law firm: AI that knows your precedents.

Want to see it on your own calls and emails? Get a free diagnostic — we map one team or knowledge area and show you exactly what we'd build, the impact and the cost. No obligation.

Three real problems this solves — and who has them​

Across the EU, 21.6% of all road-freight vehicle-kilometers ran empty in 2024 — and 25.8% on national transport (Eurostat). Driver wages and fuel are roughly two-thirds of a carrier's cost base, so every empty kilometer burns the biggest cost line for zero revenue. Here is where that actually happens.

1. The empty return leg nobody had time to fill​

Who has it: a 55-truck regional carrier hauling for automotive and construction customers across the SK–CZ–AT–HU corridor — strong outbound contracts, weak structured backhaul.

The dispatcher has 30–60 minutes after a delivery to find a return load before the driver's hours and the next dispatch force the truck home empty. A 300 km empty return burns €150–420 with no one paying for it. One avoidable empty return per truck per week on a 50-truck fleet is well over a quarter of a million euros a year in variable cost alone.

How we solve it: every morning the dispatcher gets a ranked queue of concrete return-load and repositioning options that fit the truck's hours, equipment and home base — each with the empty km saved, the net contribution and a plain-language "why".

2. Freight that never reaches the optimizer because the data is a mess​

Who has it: a 25-person freight forwarder whose orders land all day as PDFs, email bodies and spreadsheet attachments from dozens of small shippers.

Hand-keying a single transport order takes 10–15 minutes (up to an hour for a complex one), and the same load detail gets retyped four or five times downstream. By the time a load is in the system, the window to combine it with something else has closed — so the matchable freight that could have killed an empty leg was never even visible.

How we solve it: the system reads the messy inbound orders directly — parses the PDF, the email, the ERP record — and drops normalized, matchable loads into the pool automatically, with a human confirming anything ambiguous. You can't optimize freight the system can't see.

3. Each depot optimizes its own trucks, so the network leaks between them​

Who has it: a 120-truck carrier with six regional depots, where each branch is measured on its own numbers.

Depot A sends a truck empty toward a region on the same morning Depot B has a load there going begging — but the two dispatchers never see each other's boards in time, and no load board will ever tell you to reassign your own committed truck. The empty repositioning piles up at the network level, where nobody owns it.

How we solve it: the system optimizes across the whole network, not one board, and proposes concrete inter-depot swaps ("reassign load #2231 to a Žilina truck already heading that way — saves one empty reposition, +€260 net") that a branch manager can see is a fair trade.

Illustrative figures grounded in industry benchmarks (Eurostat empty-running rates, IRU cost-per-km ranges). The real impact depends on your lanes and data — which is why we validate it on your own trips.

How the solution works​

All three problems share one root: at the moment of dispatch, the freight that could fill an empty leg is invisible, unmatched, or stuck in another depot. One loop closes that gap.

The system runs over real trips and every morning prepares the dispatcher a queue of concrete suggestions — ranked by confidence and savings. The dispatcher accepts or rejects them with one click, and the solution thereby learns what works in practice.

Where exactly AI helps​

Let's be precise — the kilometer savings themselves aren't produced by a language model, but by optimization: matching return trips, swapping dispatches, repositioning. That's operations math.

AI adds value where math alone isn't enough:

• reads data from all your systems — it turns orders from emails, PDFs, spreadsheets, ERP and dispatcher notes into unified data the optimization can work with,
• explains "why" for each suggestion in plain language — so the dispatcher trusts it and actually uses it,
• handles incomplete and messy data without the whole process grinding to a halt.

In other words: AI doesn't raise the ceiling of savings, but it decides whether anyone actually uses the system and whether it covers real, chaotic operational data.

What the morning suggestion queue looks like​

Each suggestion is concrete — vehicle, route, reason and a quantified saving. A sample from a pilot simulation over real trips:

The system does nothing behind the dispatcher's back. It suggests, quantifies and explains "why" — the decision stays with the human.

Impact during the pilot​

As accepted suggestions accumulated, the share of empty kilometers in a simulation over real trips (January–May 2026) gradually dropped from 22% to 17% — roughly a fifth of empty runs.

Fewer empty kilometers means direct savings on fuel and driver time — and more capacity for paid trips without a single new vehicle.

What it means in euros​

On a model fleet of 200 trucks (120,000 km/year per vehicle, avoidable cost ~€0.55 per empty kilometer) the annual saving works out as follows:

The realistic scenario means ~€660,000 a year (~€3,300 per vehicle) — without a single new truck, just by better using the ones already on the road.

Model estimate. The numbers are based on the stated assumptions and serve to give a sense of the order of magnitude. The actual result depends on the type of transport, region and data quality — which is why we validate it on your own data, not on promises.

Why it works better than classic reporting​

Classic reporting tells you there are a lot of empty kilometers. It doesn't tell you what to do about it today. The difference is in three things:

• A suggestion instead of a number — the dispatcher gets an action, not a chart.
• Confidence and saving at every step — they know what to prioritize.
• Learning from decisions — the more suggestions go through, the more accurate the next ones.

Who it makes sense for​

We see the biggest impact with carriers that own their fleet, where many trips are planned daily and return trips often stay empty. Fix the three problems above and the business case is simple: fewer empty legs, more paid trips per driver, and a lower cost per kilometer — without buying a single new truck, and with the driver-hours you already struggle to hire spent on revenue instead of deadhead.

A dispatcher that cuts empty kilometers is one concrete AI agent — the wider pattern is in AI agents for business: what they actually do and where to start, and our AI solutions overview shows where it fits.

If that's you too, get a free diagnostic on your own data — we map it and show you exactly what we'd build, the impact and the cost. No obligation.