Days to Invoice: The Metric Your Aging Report Can’t See

Days to invoice is the number that your aging report never shows you. For most finance teams, it’s where a surprising chunk of the cash cycle now sits.

Start with the report itself, because it earns its reputation. An accounts receivable aging report shows you which customers are drifting and where collection risk is building.

It flags the accounts that quietly slipped past their due dates, and the ones where a process is breaking before anyone escalates. Catch any of that early, and it’s a small fix. Catch it in the quarterly review, and it’s a cash problem.

So here’s the gap worth knowing about.

Every bucket in an aging report counts from the invoice date. That’s the whole timer. The report starts tracking the moment an invoice is created in your system, and it treats that as the moment your customer received it.

For most of invoicing history, close enough. You generated it, you emailed it, the same afternoon.

Then your enterprise customers moved to AP portals.

Why does nobody measure days to invoice?

Because on paper, there’s nothing to measure. An invoice should go out the day you issue it. Generate, send, done. You wouldn’t build a KPI around a step that takes 4 minutes, which is why you won’t find it in the metrics AR teams already track.

But portal submission isn’t sending. It’s a sequence. Find the purchase order and match the invoice against the purchase order. Split the line items, hunt down the supporting attachments and upload them.

Correct the tax treatment, line up the item numbers with the PO, then fill in the rest. Submit, wait, get it back with an error, fix it, submit again.

Every one of those steps is somewhere an invoice can stop. The customer hasn’t funded the PO yet. The attachment sits with someone who’s out this week. A field wants a format nobody documented, so your billing specialist learns it by getting rejected.

Then she starts over for the next customer. Different portal, different rules, different approval workflows. Over 600 of these portals exist, and no two behave alike, which is how manual processes quietly stretch the payment process at the front end.

So the work is real, the days are real, and none of it shows up in the report. Teams who’ve handed portal submission to software aren’t losing days here. If yours still does it by hand, your team spends those days and nobody counts them.

Your customer takes the blame for it

Here’s what the gap actually does.

An invoice clears the portal on day 22. Your customer pays on net 30, exactly as agreed, the way they always do. Your aging report drops it into the 60+ bucket with their name on it.

Now the account looks like a problem. Someone suggests reviewing their credit terms. Someone else sends collections after a customer who was never late.

The delay genuinely happened. But your report flags it as someone else’s behavior, which makes it one of the quieter reasons a DSO looks too high with no obvious cause.

How to get your own days to invoice number

Two dates, one afternoon, no new system.

Take the creation date from your ERP. Take the accepted or submitted date from the portal, which most of them show in the invoice history. The difference is your days to invoice.

Run it across one quarter for your 5 largest portal customers. That’s enough, because the days almost never spread evenly. A handful of customers with the most demanding portals tend to carry most of it. They’re often the same names already sitting in your worst bucket of unpaid invoices.

Then split each customer’s days outstanding into two categories: days before submission and days after. Same total, and suddenly a very different conversation.

When someone asks why that account is always late, you have an answer. 22 of those days were ours. The other 30 were terms, and the customer paid on time.

Two things to do with that once you have it.

First, bring the before-submission number to your next cash review. It shifts the discussion from which customers are slow and turns a vague complaint into informed decisions about where to spend effort.

Second, look at what’s driving it per customer, since the reasons differ. One account might be waiting on POs nobody has funded. Another might fail the same tax field every month, which is a 10-minute fix you just need to tell someone about.

After that, you’re deciding whether a person should keep doing this work at all. Monto’s AI agents take the submission stretch off your team. Each agent learns its customer’s portal, then moves invoices from your ERP through to payment. That’s how you improve cash flow without anyone having to chase harder.

But get the number first. It tells you which customers to start with, and connecting your ERP to customer portals becomes a different decision once you can see what the manual version costs.

FAQ

What is days to invoice?

The time from creating an invoice in your ERP to your customer’s system accepting it. It’s the delay that happens before your aging report starts counting.

How is days to invoice different from DSO?

DSO runs from the invoice date to payment. Days to invoice run from creation to submission, and the stretch DSO is treated as zero.

Why doesn’t the aging report show submission delays?

Your aging report calculates its buckets from the invoice date on the document. If that document sat for weeks before your customer saw it, the report still counts those weeks against them.

Should we track days to invoice?

Yes, if a real share of your revenue comes from customers who require portal submission. If you invoice by email, the days to invoice are close to zero, and there’s nothing worth tracking.