Explainer

The Payables Your Treasury Forecast Can't See

An invoice is a known obligation the day it arrives. In most groups it becomes visible weeks later, at posting. What changes when it arrives structured.

Invoice & AP automation

5

min read · Updated

September 4, 2026

For PO-backed spend, your forecast is already in decent shape. The commitment shows up when the order's released, and the receipt confirms delivery. That part works fine. Everything else is where the trouble hides.

A non-PO invoice arriving on the third of the month is a known obligation from that moment, and in most groups it becomes visible to treasury only when someone enters it, which might be the twenty-fourth. For three weeks the money is committed and the forecast can't see it. Add the invoices that arrived and were never entered at all, and you have the volatile part of your payables sitting outside every number your CFO looks at.

The weeks when the money is owed and the forecast can't see it

This isn't a treasury problem, and no forecasting tool fixes it, because the data doesn't exist yet in a form anything can consume. It exists as a PDF in a mailbox, or as a document in a queue waiting for a person to work out who owns it.

The forecast quality your CFO complains about is a function of how quickly AP turns documents into structured obligations. Everything downstream is impacted by this lag.

What "structured on arrival" actually means

It's a specific list rather than a figure of speech. On the day the invoice arrives, five things need to be known:

  • The amount and currency, at line level where the entity needs it.
  • The legal entity that owes it, assigned from the ERP rather than inferred from the mailbox it landed in.
  • The due date, derived from the payment terms that actually apply.
  • The supplier, matched to the master record instead of to a name string.
  • The confidence. Whether this obligation is settled, likely, or blocked by an exception that might change it.

That last item is the one treasury values most and the one AP is least used to producing. A forecast that distinguishes committed from contested is worth considerably more than one that shows a single number.

The due date is a legal fact more often than a preference

Payment terms feel like a commercial negotiation until you look at what constrains them. The EU's late payment directive makes 30 calendar days the fallback where the contract fixes no period, running from receipt of the invoice by the debtor. A contractual term can take it to 60. Beyond 60 you need an express agreement and it must not be grossly unfair to the creditor. And there is a clause your AP function meets every week without knowing it: where a goods acceptance or verification procedure applies, the clock runs from that date, and the procedure itself is capped at 30 days. Your incoming inspection is that procedure, and it moves your due dates.

And in some jurisdictions the clock doesn't start when you think it does. Under Poland's national system the date an invoice counts as received is the date its KSeF number is assigned, which means your payment deadline can begin before anyone in your AP team has opened the document.

A forecast built on the date the invoice reached your inbox is already wrong in those entities.

Where AP data stops and treasury begins

Be strict about this boundary, because blurring it is how these projects fail. AP owns the obligation: what's owed, by which entity, when it falls due, and how certain that is. Treasury owns the decision: what gets paid, when, from which account, in which currency.

AP shouldn't be forecasting cash. It should be producing the input treasury has been estimating, and doing it on the day the document arrives instead of three weeks later.

What FP&A does with it on a Thursday

The weekly conversation stops being an accrual estimate with a tolerance band. The analyst opens a payables position that shows committed obligations by entity and week, plus a smaller contested bucket with reasons.

The questions become answerable. Which of these could move if we chased the exception. Which entity is carrying an unusual load this week. Where would taking an early-payment discount actually pay for itself.

What Hypatos adds to the payables line

The invoice processing workforce structures the invoice on arrival, which is the whole mechanism here. Supplier matched against master data, legal entity assigned from the ERP, coding proposed, due date derived from the terms that apply, and the exception state visible from day one instead of discovered at posting.

That turns a monthly reconstruction into a feed your own reporting can consume, because the fields treasury needs exist on day one instead of on posting day. The agent proposes, a named person decides, and the record shows what was checked, so an obligation that is contested is contested for a reason somebody can read.

Hypatos fits when your forecast depends on obligations that exist in documents nobody has processed yet, and when the gap between arrival and visibility is measured in weeks.

How much of last quarter's cash was visible on day one

Take last quarter. For each invoice, measure the gap between the date it arrived and the date it became visible to whoever builds the forecast.

The median of that gap is the number to improve. It's also the number no one in your organisation currently owns, which is usually why it's as large as it is.

Put it in front of whoever is proposing to change your AP process, Hypatos or anyone else, and ask what it would look like after six months.

In this article

Overview

How IDP works — and where the category has moved

The IDP vendor landscape: who leads and where

Accuracy benchmarks: what the numbers actually mean

ERP integration: SAP, Oracle, and Dynamics

Selecting by use case: AP, logistics, HR, and contracts

Deployment architecture and total cost of ownership

How to evaluate IDP vendors for your document portfolio

Related articles