Money Moves in Seconds Now. Your Billing Code Is the Bottleneck.

A transfer sent over the Federal Reserve's instant payment rail lands in the recipient's account within seconds, even at 3 a.m. on a Sunday. The invoice behind that transfer may have needed the better part of two months to get there, crawling through a month-end batch job, a shared accounts-payable inbox, two approval queues and a reconciliation spreadsheet that someone updates on Fridays. That gap is exactly why the argument that cash velocity, not revenue, has become the real test of business strength deserves a developer's attention and not only a CFO's. How quickly earned money turns into money a company can actually spend is now decided less by banks and more by software, and a lot of that software is written by people like us.

The Banks Stopped Being the Excuse

For most of the history of business payments, slow money had an alibi. ACH moved in batches that typically settled a business day or two later, wires paused for weekends and holidays, and a paper check could spend a week traveling and clearing. Nobody outside a bank could do much about any of that, so engineering teams treated the payment timeline like the weather.

That alibi has expired. On July 20, 2023, the Fed launched FedNow, its round-the-clock instant payments service, which lets banks and credit unions of any size move money for their customers at any hour, on any day of the year. Jerome Powell's launch statement even used our scenario as a selling point: a company getting immediate access to its funds when an invoice is paid. Europe went a step further and turned speed into an obligation. Under the Instant Payments Regulation, banks in the euro area have had to accept instant euro transfers since January 2025 and send them since October 2025, at a price no higher than a regular transfer and with a free check that the payee's name matches the account number. The European Central Bank's guide to the Instant Payments Regulation lays out the staggered deadlines, which reach the EU countries outside the euro area in 2027. Add the UK's Faster Payments, India's UPI and Brazil's Pix, and instant transfers are an everyday habit for hundreds of millions of people.

So the interbank leg, the part everyone used to blame, can now take seconds. What stays slow is everything that happens before someone presses "send," and everything that happens after the money lands but before anyone knows what it was for. Both of those are software.

Follow One Invoice and Watch Where the Days Go

Pick an ordinary B2B invoice from last quarter and replay its life as a timeline. The client signed off on the work on the 3rd, but invoices come out of a month-end batch job, so the bill didn't exist until the 1st of the following month. It traveled as a PDF attached to an email, landed in a shared accounts-payable mailbox and waited for someone to key it into the customer's ERP. It bounced once because the purchase order number was missing. It waited a week for an approver who was on holiday. It was slotted into the customer's weekly payment run. When the money finally arrived, the reference field read something like "INV2231 2232 PART," and someone on your side lost a morning working out which invoices it covered and why it was short.

Not one of those delays happened inside a payment network. Each lives in a system somebody designed: a cron schedule, an email template, an import script, a validation rule, a matching spreadsheet. The money itself was in motion for a few seconds. Everything around the money took seven weeks.

Payment Messages Finally Have Room to Explain Themselves

The second shift is quieter, and it matters even more to anyone who writes integration code. For decades most payments carried only a few cramped lines of free text about their purpose, which is why matching money to invoices turned into a manual craft. That is changing. The Fed moved Fedwire, its wholesale wire system, to the ISO 20022 message standard in a single-day cutover on July 14, 2025, and Swift ended the period in which banks could still use legacy MT messages for cross-border payment instructions on November 22, 2025. FedNow and Europe's instant payment schemes were built on ISO 20022 from day one.

The part developers should care about is structured remittance data. An ISO 20022 payment can reference specific invoices in fields software can parse, instead of a string a human has to decode. If your invoices carry a unique, machine-readable reference, and your payment links and bank instructions pass it through untouched, matching a payment to an invoice stops being detective work and becomes a database join. Finance teams call the result automated cash application. Engineers can simply call it deleting a manual step.

The Invoice Is Becoming an API Payload

The document is changing as well. France's e-invoicing mandate went live on September 1, 2026: every VAT-registered business established there must now be able to receive electronic invoices through an approved platform, large and mid-sized companies must also issue them, and smaller firms join on the issuing side in September 2027. Germany has required businesses to accept e-invoices since January 2025, and the EU's VAT in the Digital Age package, adopted in March 2025, makes e-invoicing mandatory for cross-border B2B trade inside the EU from July 2030.

A PDF is a picture of data. A structured invoice is the data itself, and that changes what the receiving side can automate: validate it on arrival, match it to a purchase order, route it to the right approver and schedule the payment without anyone retyping a line. Each of those steps used to be a queue measured in days. If you build billing, procurement or accounting software, this is the moment when "export to PDF" stops being a feature and starts being technical debt.

What to Build Before the Next Billing Cycle

None of this needs a banking license. It needs someone to treat the path from "work accepted" to "cash applied" as a product surface rather than a back-office chore. These changes offer the best ratio of engineering effort to days saved:

• Invoice on the event, not the calendar. Generate the bill when a milestone is accepted or a usage period closes. A month-end batch can quietly add almost a month of dead time before the customer even sees a number.
• Give every invoice a machine-matchable identity. Use a unique reference that survives the trip through the payment message, or assign each customer a virtual account number, so incoming money identifies itself.
• Put a pay-now path inside the invoice. A payment link or bank instruction that works over instant rails removes the wait between "approved" and "paid." FedNow and The Clearing House's RTP network both support request-for-payment messages, so ask your bank or payment provider what it exposes.
• Ingest bank data as events. Pull intraday reports and payment notifications (camt.052 and camt.054 in ISO 20022 terms, or your provider's webhooks) instead of a once-a-day CSV, and apply cash automatically whenever the reference matches.
• Validate before you send. Block your own invoice if the purchase order number, tax ID or billing contact is missing. A bounce your code catches costs seconds; a bounce the customer's AP team catches can cost a week.
• Make disputes loud. A rejected or disputed invoice should open a ticket with an owner and a deadline instead of sitting unread in a shared inbox.

Find Your Slowest Stage With One Query

Days sales outstanding tells you how long collection takes overall, but not which stage to fix. For that you need timestamps. If your billing system writes a row to an invoice_events table each time an invoice changes state (work_accepted, invoice_sent, invoice_approved, payment_scheduled, payment_received, cash_applied), this PostgreSQL query shows how long invoices sit in each stage and what share of all waiting time each stage owns:

WITH steps AS (
  SELECT
    invoice_id,
    stage,
    occurred_at,
    LEAD(occurred_at) OVER (
      PARTITION BY invoice_id ORDER BY occurred_at
    ) AS left_at
  FROM invoice_events
  WHERE occurred_at >= now() - interval '120 days'
)
SELECT
  stage,
  COUNT(*) AS invoices,
  ROUND((percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM left_at - occurred_at)
  ) / 86400)::numeric, 1) AS median_days,
  ROUND(100 * SUM(EXTRACT(EPOCH FROM left_at - occurred_at))
    / SUM(SUM(EXTRACT(EPOCH FROM left_at - occurred_at))) OVER ()) AS pct_of_total_wait
FROM steps
WHERE left_at IS NOT NULL
GROUP BY stage
ORDER BY pct_of_total_wait DESC;

Each row describes the stage an invoice was sitting in and how long it stayed there before the next event, so pct_of_total_wait is the column to sort your backlog by. When invoice_sent dominates, the delay looks like the customer's fault, yet the cure is often on your side: a missing PO field, an invoice delivered to the wrong mailbox or a format their system can't ingest. When payment_received is large, your own reconciliation is the bottleneck, and the machine-readable references described above are the fix.

Speed Is a Design Decision Now

When money needed days to cross the banking system, cash velocity looked like something the banks controlled. Now that money can move in seconds, a seven-week gap between delivering value and being able to spend the proceeds is mostly the sum of small choices: one batch schedule, one PDF template, one manual matching rule at a time. Companies that close that gap fund their next hire, their next experiment and their next bad quarter with their own money instead of someone else's. And the people best equipped to close it are the ones who already spend their days finding the slowest stage in a system and engineering it away.