How Psiog traced a cash-conversion shortfall to its earliest point of failure, and got the first fix into production
Customer Details
Client:
EPC infrastructure services provider
Scale:
~$240M revenue, 25+ US locations
Estate:
RentalMan, Oracle Fusion, Boomi, ServiceCore
Summary
“Days sales outstanding” (DSO) stood at 69 days, 24 days above the 45-day industry benchmark and above the customer’s internal target. Around $30M was sitting in open receivables.
When DSO is high, the usual response is to focus on collections. Psiog looked one step earlier in the process and found that invoices were not always reaching customers on time. Preparing a single invoice took around 28 minutes of manual work across multiple systems, and some invoices were never sent. If an invoice is not sent, the issue is not with collections. It means that the revenue has not even entered the cash cycle yet.
Psiog built and deployed a Billing specialist agent to automate invoice delivery from start to finish. The time taken to process an invoice dropped from 28 minutes to under 15 seconds, a 99.13% reduction. At the current volume, this is estimated to free up around 250 to 280 hours of operational capacity each month.
Landscape
The customer generates revenue primarily through equipment rental fees, charging customers a periodic rate to deploy and maintain equipment at their job sites. Revenue accrues daily or monthly against active rental agreements. Alongside the core rental business, the customer has also built a proprietary technology layer covering surveillance, connectivity, IoT monitoring, and generator monitoring. These services carry higher margins and have more recurring characteristics than the legacy rental model and now make up a meaningful share of overall revenue.
The customer’s order-to-cash process runs across six stages, from prospects and quotes through cash receipt and AR close. The process spans Salesforce, RentalMan, Oracle Fusion, a customer portal, and an e-billing layer. Psiog mapped the process down to the sub-process level, validating each step against the source systems and clearly separating what was verified from what was inferred.
Invoicing sits in the middle of this process. It comes after contracts and service delivery, but before collections and cash receipt. The downstream stages depend on invoices being generated and delivered correctly.
Operating Pressures
When DSO is high, the first instinct is usually to look at collections. That focuses on the symptoms rather than where the problem starts. DSO is the result of several steps in the process, so we looked at what was happening earlier in the cycle.
We traced the order-to-cash cycle stage by stage instead of starting with the most visible problem. This brought us to a more basic issue: invoices were not consistently reaching customers in the first place. There was no metric for this stage, because an invoice that was never sent does not appear in an ageing report.
The gap came from a very manual process. To send a single invoice, billing staff had to move between multiple systems to find the customer record, confirm the correct email address, retrieve open invoices, determine which entity in the customer’s corporate hierarchy the invoice belonged to, assemble the documents, and send them manually.
Step | Time (minutes) |
Checking customer email addresses | 5 |
Fetching invoices | 2 |
Resolving parent-child hierarchy | 5 |
Packaging invoices | 2 |
Drafting the email | 5 |
Routing for approval | 2 |
Sending to customer | 2 |
Logging the entry | 5 |
Total per invoice | 28 minutes |
At an estimated 600-700 invoices a month, this was a ceiling on how fast revenue could be converted to cash and was a source of unbilled revenue.
Approach & Design Direction
Every candidate workflow across the order-to-cash process went through the same assessment before we started building. We looked at the manual steps involved, effort per transaction, volume, error rate, systems touched, approval requirements, and what would happen if the automation failed. This assessment resulted in eleven candidates covering areas from quote-to-order and contract activation to aging alerts, cash matching, and dispute triage.
Two areas stood out: billing and invoicing, where the manual effort was highest and directly affected revenue recognition, and collections and follow-up, which was the logical next step once invoices could be sent reliably.
We chose billing because it was the first point in the process that was holding up the downstream activities. Collections, dispute resolution, and overage capture all depend on invoices being generated and delivered correctly.
The same thinking shaped the solution design. We automated steps that followed clear rules and kept human involvement where a decision was required. Invoice delivery is largely deterministic. Given a contract, a customer, and a delivery status, the system can determine which invoices need to be sent and to which recipients. The priority was therefore to make that process reliable enough to run consistently at the required volume.
Agentic Techniques & Tools
Lang Graph orchestrates a fixed pipeline inside one runtime boundary; a human approval gate and delivery sit outside it. Supporting systems below are shared across steps, not owned by any single one.
Built on a Lang Graph agentic architecture, the solution separates rule-based automation from judgment work by design.
- Automation: Scheduling, invoice retrieval, hierarchy resolution, packaging, and delivery run without manual intervention. These steps follow fixed rules and use templated content rather than generative output. This keeps invoice amounts, counts, and email wording consistent.
- Human-in-the-loop: Each schedule can require process-owner approval before a batch is sent to the customer. This is enabled by default and can be configured for each schedule.
- LLM Reasoning: The architecture supports LLM-based steps, and the framework already provisions an Azure OpenAI client. However, no LLM reasoning step is currently active for this use case because the workflow does not require it.
- Data layer: Postgres is the system of record for run history, schedules, HITL decisions, and the audit trail, along with LangGraph’s state checkpointing. Redis is used as a performance cache for customer lookups and the RentalMan invoice cross-check, which identifies invoices that have not yet synced to the data warehouse. If Redis is unavailable, the system falls back to a live query.
- Idempotency: A run can be safely retried without sending the same invoice twice. Before sending it, the pipeline checks whether the invoice has already been delivered and skips it if it has.
- Reliability & Guardrails: A short-lived lock prevents duplicate sends if a schedule fires while another run is still in progress. A live RentalMan check catches invoices that have not yet synced to the data warehouse. Large invoice batches are split across multiple emails when required, and everything is recorded in the audit trail.
Agents act only through a defined, auditable path. Approval sits with a human wherever a schedule requires it and customer-facing risk is involved. Every run is logged.
Per-Invoice Decision Flow
A single schedule firing for one customer or location can end in five different ways, and only two of them result in an email being sent. The diagram below shows the full decision flow. Each decision point is based on a fixed check against the current system state rather than a judgment call. This makes it safe to retry or re-trigger a run without repeating an invoice that has already been sent.
HITL Pause/Resume Lifecycle
A batch paused for human approval is checkpointed rather than held only in memory. If the container is redeployed or crashes while the batch is waiting, the graph can resume from the point where it was paused instead of starting the process again.
How Each Step Is Automated
Each step from the manual process has a named, inspectable equivalent in the pipeline.
Manual Step | Automated Equivalent |
Checking customer email | check_email — resolves override → directory → RentalMan default, in that order |
Fetching invoices | fetch_invoices — DW cube pull, cross-checked against RentalMan live for sync lag |
Resolving hierarchy | resolve_hierarchy — looks up which corporate entity a customer's account rolls up to, from a cached customer-master record shared with the email-lookup step. |
Packaging | package_pdfs — fetches each invoice PDF from RentalMan, zips them, splitting into multiple parts if size limits require it. |
Drafting | draft_email — fixed template; wording never varies invoice-to-invoice |
Approval | HITL gate — configurable per schedule, on by default |
Sending | send_email — shared Mailgun delivery layer for both agents, logging every send to the audit trail. |
Logging | write to Postgres run/audit tables |
Impact & Business Value
Measure | Before | After |
Cycle time per invoice | 28 minutes, manual | Under 15 seconds (99.13% reduction) |
Invoice delivery reliability | Manual, prone to delay and omission across system handoffs | Automated, consistent delivery via governed workflow |
Monthly capacity | - | 250-280 hours reclaimed, at estimated 85% adoption |
DSO | 69 days (against 45-day benchmark) | Yet to be measured |
Dollar value of hours reclaimed | - | ~$10000 (based on adoption) |
Cycle-time and savings figures are measured rather than modeled. Each pipeline step records its effort against a configured per-step rate during every production run, so the savings figure is based on actual usage rather than a one-time benchmark.
Hours reclaimed is calculated from the measured time savings and expected adoption. The dollar impact is then calculated based on the same adoption assumption.
What This Means for Business
Invoices no longer must wait in a person’s queue. The process is no longer limited by the time available to billing staff, so it can handle changes in invoice volume without requiring the same increase in manual effort. There is also a more important benefit that does not show up in the before-and-after numbers. An invoice that is never sent does not appear as overdue because it never reaches the collections process. Improving invoice delivery therefore does more than save time. It helps ensure that revenue is billed in the first place.
This fix will not close the 24-day DSO gap on its own. The purpose of this workflow was to address the upstream issue that collections and cash application depend on. It also provides the starting point for the next two workflows.
Way Forward
Billing came first because it was the earliest point where the process was breaking down. It was not the only opportunity identified during the diagnostic. The same assessment also surfaced the next two areas, both of which are already in progress.
- Collections and follow-up – This is the natural next step now that invoice delivery can be relied on. Aging-based follow-up, escalation, and dispute handling can be automated around invoices that have reached the customer, rather than working with an incomplete input.
- Overage billing – This addresses a different type of revenue leakage. Services can be delivered beyond the contracted thresholds without being invoiced. The focus here is on identifying that additional billable revenue and capturing it through the same infrastructure.
Each process component will be assessed based on its own evidence, as billing was. Together, these improvements are intended to address the broader DSO gap. Billing is the first workflow that has already been implemented and proven using Agentic Architecture.
