What is cost per invoice, and what's a good invoice cycle time?

Fully loaded or it's fiction: AP labor (including allocations of people who spend part-time on AP work), software costs, error and rework costs (duplicate recovery, late fees, reclasses), and a defensible share of overhead. Labor-only numbers understate cost by half and make automation business cases look weaker than they are. Compute it both ways - labor-only for trend tracking, fully loaded for decisions - and document the formula so the number survives challenge.

Instrument four timestamps: received -> captured/coded, coded -> approval-complete, approved -> payment-scheduled, scheduled -> paid. In most manual environments, approval is the dominant stall (often more than half of total cycle time), followed by capture lag for invoices sitting in inboxes. Measure stage medians *and* 90th percentiles - averages hide the stragglers that damage vendor relationships - and attribute approval time to specific routing steps so fixes are targeted rather than general exhortations to "approve faster."

Treat published benchmarks as ranges, not targets: smaller-volume teams run higher unit costs (fixed costs over fewer invoices), and high-volume automated operations push toward the low single digits. Your own trend quarter-over-quarter is more decision-useful than cross-company comparisons with inconsistent formulas.

Elapsed days from invoice receipt (system entry - and measure receipt-to-entry lag separately if invoices dwell in inboxes) to a defined endpoint: payment-ready for process efficiency, paid for vendor experience. Define the endpoints once and hold them constant; most cycle-time "improvements" in vendor slides are endpoint redefinitions.

Commonly cited figures put manual environments at 10 - 17 days and top-quartile automated teams under 5. PO mix moves it: PO-backed invoices that match cleanly can be near-instant, while non-PO invoices carry full approval cycles. Compare against your payment terms - a cycle time near your net terms means you're chronically at risk of late payment.

Build it bottom-up with named components: salaries × AP time allocation, software line items, measured error costs (duplicates found, late fees paid), and a stated overhead method. Show the formula, show the sensitivity (what if labor allocation is 20% lower?), and pre-concede the soft spots. CFOs reject point estimates with hidden math, not honest ranges.

Substantially: a clean PO-backed invoice should approach touchless (match, post, schedule - days or hours), while non-PO invoices carry coding and approval cycles. If your PO-backed invoices aren't meaningfully faster, your matching isn't working; if non-PO invoices are faster, your PO process is adding friction without control.

Report the distribution, not the mean: median plus 90th percentile, and a straggler count (invoices over X days) with root-cause categories. The stragglers are where late fees, vendor escalations, and audit findings live - a good average with a fat tail is a worse operational position than a mediocre average with a tight distribution.

Publish process-level stats first (approval time by department or workflow stage), share individual data privately with the approver before any wider audience, and frame the metric around invoice outcomes (late payments caused) rather than personal speed. Most slow approvers are drowning in context-free requests - fix what approvals look like before blaming who performs them.

Stampli compresses the two stages that dominate cycle time. Capture-to-coded shrinks because Stampli AI extracts data and suggests coding the moment an invoice arrives - on average performing 87% of the structured field-level work, with human review before posting. Approval shrinks because everything an approver needs - document, coding, history, conversation - lives on the invoice itself, so questions get answered in context instead of in email threads. The platform ROI is the KPI outcome: shorter cycle times, fewer exceptions, and faster closes without downstream cleanup.