Accounts Payable Dashboard: The Six Numbers Worth Putting on It
An accounts payable dashboard should show six numbers, not fifteen. Which metrics earn a tile, where each one comes from in your system, and which popular AP KPIs to leave off.
Ken
AI Finance Assistant
Accounts Payable Dashboard: The Six Numbers Worth Putting on It
An accounts payable dashboard is a working screen that shows the state of invoices currently moving through AP — where they are, what is holding them up, and what money is committed in the next few weeks. It is a specification, not a report: every number on it names a thing someone can do today.
That is the whole difficulty. Most AP dashboards are built by listing the metrics the AP function is measured on and putting each one in a tile. That produces a screen full of quarterly numbers refreshed nightly, which is a report with a faster clock. The list below is built the other way round — from the decisions an AP manager makes in a week, backwards to the smallest number that would change one of them.
The test a number has to pass
A tile earns its place if the number can move before the next time someone looks at the screen.
Run any candidate metric through that. Cost per invoice moves when you change headcount, software, or volume — three or four times a year at most. Put it on a daily screen and it is the same figure for eleven weeks running, teaching everyone who walks past it that the dashboard does not change. Approval queue age moves within an hour of someone clearing a queue. One of those belongs on a wall; the other belongs in a quarterly pack.
This gives a second, harsher rule. If a metric cannot move faster than the review cadence, moving it to the dashboard does not make it more actionable — it makes the dashboard less trusted. The cost of a decorative tile is not zero. It is paid by every real tile next to it.
The six numbers
Each one below is given with its exact definition, the record in your system it comes from, and the action it triggers. The definition matters more than the visual: two teams reporting "cycle time" are usually measuring different intervals, and the number is worthless the first time someone asks which.
1. Oldest invoice in each approver's queue
Definition: for every approver with at least one open item, the age in hours of their oldest unactioned invoice. Not the average. Not the count. The oldest.
Source: the workflow or approval task table — the row created when an invoice is routed and closed when it is actioned. In most systems this is a separate table from the invoice header, and it is the one most likely to be missing history if the workflow module was configured to overwrite rather than append.
Action: the number names a person. Averages hide the one approver on holiday with forty items behind them; the oldest-item view puts their name at the top of the list and the fix is a message, not an analysis. Show it as a ranked list of approvers, not a gauge.
2. Exception backlog by reason code
Definition: count of invoices currently on hold, grouped by why. PO quantity mismatch, price variance, no goods receipt, missing PO, duplicate suspicion, tax mismatch, vendor bank detail change.
Source: the hold or block reason on the invoice record. If your system stores a single generic "on hold" flag with a free-text note, that is the first thing to fix — a coded reason field is worth more than the entire rest of the dashboard.
Action: the grouping is the insight. A backlog that is 60% price variance is a purchasing problem, not an AP problem, and the fix sits with whoever maintains the price list. A backlog that is mostly missing goods receipts is a receiving problem in the warehouse. Fixing categories retires exceptions permanently; fixing individual invoices retires them once. See three-way matching for where most of these reasons originate.
3. Discount value expiring in the next seven days
Definition: the sum of discounts still capturable — invoices whose early-payment discount date falls inside seven days and which are not yet approved for payment. Expressed in currency, not count.
Source: the vendor payment terms field joined to the invoice date. This is arithmetic your ERP can already do; it is almost never shown because discount capture is usually reported after the fact, as a percentage, once a month.
Action: this is the one tile that converts directly into money in the same week. A number in currency also survives contact with a CFO in a way a percentage does not. When it is high, the escalation is specific: these four invoices, this approver, by Thursday. Reported monthly as a capture rate, the same information arrives after every one of those windows has closed.
4. Touchless rate on this week's intake
Definition: of the invoices received in the last seven days, the share that reached payment-ready with no human edit, no hold, and no manual coding. Measured on the intake cohort, not on everything cleared this week.
Source: invoice records filtered by receipt date, joined to any edit or intervention record. Cohorting by receipt date is what makes this leading rather than lagging — measuring "invoices completed this week" mixes in a tail of old exceptions and moves for reasons that have nothing to do with current performance.
Action: a fall in the weekly cohort rate is an early warning that something upstream changed — a new vendor sending a format the extraction does not read, a coding rule that stopped matching, a supplier that started emailing PDFs as photographs. Caught in a week, it is a configuration change. Caught in a month, it is a backlog. This is the metric AP automation is actually judged on.
5. Time in stage, split five ways
Definition: median hours spent in each of intake, extraction and coding, matching, approval, and payment scheduling — five separate numbers, not one total.
Source: status-change timestamps on the invoice. This is the entry that is most often unavailable, because status history is a configurable audit table that many ERPs ship disabled or set to purge after thirty days. Turning it on is usually a settings change and is the highest-value single thing you can do before building anything.
Action: total cycle time tells you that AP is slow, which nobody disputed. The split tells you which of five different teams owns the delay, and the answer is frequently not AP. Publishing the split is also the fastest way to end the argument about whether AP or the approvers are the bottleneck.
6. Committed cash by week, four weeks out
Definition: the total due, bucketed by week, for everything approved and scheduled, plus everything approved and not yet scheduled.
Source: the payment proposal or payment run table, plus approved invoices with a due date and no payment record. Keep the two components visible separately; the second is the one that surprises people.
Action: this is the tile that makes the dashboard interesting to someone outside AP. It gives treasury a forward view built from the actual approved population rather than from an average, and it lets AP prioritise sensibly when a week is heavy. It also connects directly to cash flow forecasting, where AP is normally represented by a single smoothed line.
What to leave off, and why
These are not bad metrics. They are reporting metrics wearing a dashboard costume, and each fails the movement test above.
| Metric | Why it fails as a tile | Where it belongs |
|---|---|---|
| Cost per invoice | Moves with headcount and volume, quarterly at best; needs allocated labour to compute honestly | Quarterly finance review |
| Days payable outstanding | Steered by payment policy and negotiated terms, not by AP execution; improving it can mean paying later, not working better | Treasury reporting |
| AP turnover ratio | Derived from period balances; cannot move inside a week | Board pack |
| Total invoices processed | A volume count, not a performance measure; rises with a good month and a bad one alike | Capacity planning |
| On-time payment percentage | Lagging by definition — it can only be computed after the deadline it is meant to protect | Vendor reviews |
| Invoices per FTE | Sensitive to invoice mix and seasonality; drives the wrong behaviour when watched daily | Annual staffing model |
The pattern is consistent: everything on the left is an outcome, and every outcome is measured after the point at which anyone could have influenced it. A dashboard's job is to show the things still in flight.
Getting the data out
Three practical obstacles come up in roughly this order.
Status history is off. Numbers 1 and 5 both depend on timestamped status changes. Check whether your system retains them before designing anything; if it does not, enable retention and accept that the two tiles arrive a month later than the rest.
Hold reasons are free text. Number 2 is only useful grouped. If reasons are typed into a notes field, replace it with a short coded list — eight options is plenty — and backfill nothing. The grouping becomes useful within a fortnight.
Payment terms live on the vendor, not the invoice. Number 3 needs the terms that applied to that invoice at that time. If terms are read live from the vendor master, a renegotiation silently rewrites history. Stamp the terms onto the invoice at intake.
None of these need a new tool. All three are configuration in systems you already run, and every one of them is a prerequisite that surfaces halfway through building a dashboard if it is not handled first.
Building it in order
- Enable status history. Nothing time-based works without it.
- Code the hold reasons. Two weeks of coded data beats two years of notes.
- Build tiles 1, 2, and 3 first. They need the least data and produce the fastest visible wins.
- Give every tile a threshold. A number without a line is decoration; a number with a line is a decision.
- Delete anything nobody acted on after a month. Including tiles from this list, if your operation does not need them.
Key takeaways
- Definition: an AP dashboard shows the state of in-flight invoices and the actions they require, not the performance of the AP function
- The test: a number earns a tile only if it can move before the next time someone looks at it
- The six: oldest invoice per approver, exception backlog by reason, discount value expiring in seven days, touchless rate on the weekly intake cohort, time in stage split five ways, and committed cash by week
- Leave off: cost per invoice, DPO, AP turnover, volume counts, on-time payment percentage, and invoices per FTE — all outcomes, all measured too late to steer
- First move: turn on status history and code your hold reasons before designing a single tile
Related Terms
- Accounts Payable KPIs - The wider metric set, including the reporting numbers this page leaves off the dashboard
- Accounts Payable Automation - What the touchless-rate tile is measuring
- Three-Way Matching - Where most coded exception reasons originate
- Accounts Payable Internal Controls - The control framework the exception tile monitors
Related Topics
Ready to automate your invoices?
See how Ken can extract invoice data in seconds, right in Slack. No credit card required.