The Definitive AR Guide: Why is my DSO still high despite AR automation?
Most B2B finance teams have a cash problem that looks like a collections problem. Invoices age. DSO creeps up. The instinct is to send more reminders and escalate faster.
This series argues the problem starts earlier, and that most of what gets sold as AR automation doesn't actually touch the places where cash gets lost.
Ten posts. Five failure points. One underlying pattern.
Who this is for
This series is most relevant to B2B companies billing other businesses on invoices: SaaS, data products, API platforms, professional services, or any business where payment isn't automatic. If your customers pay by credit card on a self-serve plan, most of what's in here won't apply.
If you're sending invoices, have more than a few dozen customers, and have a finance team spending meaningful time on AR manually (chasing payments, reconciling cash, handling exceptions), this is written for you. Whether you're a CFO evaluating whether to build or buy, a RevOps leader trying to understand why DSO stays high, or a finance or AR ops team looking for the infrastructure explanation, the series covers the full picture.
Five things most AR teams get wrong
They assume invoice creation has to be manual
Most finance teams treat contract-to-invoice as a copy-paste job: someone pulls the terms, checks the usage data, and builds the invoice by hand under deadline pressure at the end of the month. It doesn't have to work that way. An LLM that actually understands contract language can parse terms, pull the right usage figures, and generate an accurate invoice without a human in the loop. The hard part isn't the automation. It's finding a model that handles thirty-page contracts with amendments, usage components, and custom payment schedules as reliably as it handles the simple cases.
They treat every late invoice the same
The aging report makes all overdue invoices look identical. A thirty-day invoice sitting in a dead inbox looks exactly like one where the customer is slow to pay. Most AR teams respond the same way to both (another reminder, another escalation), which is why the same invoices keep aging. The first question before any collections activity isn't how to follow up. It's why the invoice is late.
They handle the same exceptions manually every quarter
W9 requests. Missing PO numbers. Out-of-office approvers. F500 portal onboarding that takes three to four weeks before a single invoice can be submitted. Every AR team has a version of these and every AR team treats them as one-off surprises. In Monk's proprietary customer data, edge cases account for 39% of the slowdown in cash flow. They are not surprises. They are a predictable category of problem that should be handled systematically, not resolved ad hoc in someone's inbox every billing cycle.
They mistake dunning for intelligent collections
A cron job that sends the same template on day 30, 45, and 60 is not automation. It's a mail merge with a timer. Customers learn to ignore it because it reads like system noise, not a real person asking about a real invoice. Intelligent collections means outreach calibrated to the customer's history, the relationship, and the root cause of why the invoice is late. It means knowing when to pause, when to escalate, and when the problem isn't behavioral at all. Julia reaches customers with a 24% higher response rate than standard dunning, based on Monk's proprietary engineering data.
They close the books before the cash is actually applied
Payment arrives. In a manual workflow, it may not close the invoice for days, or longer if the wire memo is blank, the payment is partial, or the entity name doesn't match. The aging report stays wrong. Collections may have continued on invoices that were already paid. The finance team's view of their cash position is off until someone reconciles it by hand at month-end. The loop doesn't close until someone closes it, and in most workflows that someone is doing it under deadline pressure once a month.
How to read this series
Most AR problems get diagnosed at the collections stage. We believe the break usually happens earlier, and that the best way to reduce your DSO is to fix both your collections process and the infrastructure upstream that supports it.
By the numbers
Where this came from
This series is drawn from working across B2B companies running the full contract-to-cash lifecycle, from early-stage SaaS teams billing their first hundred customers to finance teams managing complex enterprise contracts with usage components, amendments, and multi-entity structures.
The same breaks show up in the same places regardless of company size: errors baked in at invoice creation, structural delivery failures that look like slow payers, exceptions that get handled manually every single quarter, and cash sitting unmatched at month-end while the aging report says otherwise.
These posts are the infrastructure explanation for why that keeps happening. The Monk performance figures above come from proprietary engineering and customer data measured with our first 100 customers. See the methodology.