Two systems chasing the same invoice.
One runtime that ends the duplication.
Same shape of complexity.
Stop two systems chasing the same invoice.
Most AR teams run two systems that do not talk to each other. The accounting ledger chases an invoice on one cadence. A person chases the same invoice by hand on another. The customer gets two reminders for one bill, and the activity trail splits across an inbox, a CRM, and a spreadsheet nobody trusts by Friday.
It gets worse at the edges. A single bounced billing contact stalls the whole sequence for an account, and the follow-up falls back to someone's personal Gmail, where the trail goes dark. The work is real, the people are good, and the structure is still leaking days of DSO.
This runtime owns the invoice end to end instead. Each incoming wire is matched against open invoices. Each open invoice carries one follow-up trail, run by one process, recorded once. Collections happen once, reconciled once, with the full history on the account. The customer gets one professional follow-up instead of two confused ones, and the cash position is true at a glance.
Proof from the channel.
What lands in the HKR finance Slack every morning at 8 AM: the night's Wise transfers, each one already matched to the invoice it clears. No spreadsheet, no lookup, no second system.
Live post · 22 May 2026 · #ar-collections
Why it matters.
Duplicated AR work is paid for in days of DSO, customer trust, and team time. One runtime returns all three.
Cash freed, customers respectedThe cost of running AR through two parallel processes is measured in days of DSO, plus the customer-facing confusion of being chased twice for the same invoice, plus the team time that goes into reconciling the two trails after the fact.
When AR is owned by one runtime, the math reverses. Cash recovered earlier, customers contacted once, the team freed for the collections work that actually needs judgment rather than repetition.
The deeper question is who owns that runtime. A rented orchestration platform configures your workflow inside a vendor's tenant. The vendor owns the runtime; you own the configuration. When their pricing changes, an integration is deprecated, or the company is acquired, your collections cadence is downstream of someone else's decision, and your exit is a re-implementation.
This is the other shape. The runtime is plain code in your own git repository, running on a schedule in a VM you control. The same shape HKR runs for itself every day. You watched our CFO agent operate it above. What we give you is the version that runs on your data, in your environment, adapted to your stack.
That distinction quietly answers the three questions a finance leader asks before saying yes:
What if the person running this leaves? The code is in your repository, version-controlled, with no exotic dependencies and no vendor SDK to relearn. Any competent engineer can pick it up. We staff a team against the runtime, but the runtime does not depend on any one operator, on your side or ours.
What is our exit cost? Effectively nothing. The repository is yours from the first day. Clone it to a different VM, rotate the credentials, keep running. There is no platform to leave because there was never a platform between you and your own code.
What if it touches the wrong account? It cannot act on its own. Every side-effecting step waits for a human approval in Slack before it lands. The runtime proposes, a person confirms, then the action records. Nothing writes to your accounting system or sends to a customer without that confirmation in the thread.
How it actually works.
Four stages on a daily heartbeat. Deterministic where the data lives, AI judgment only where the customer interaction lives.
1 · Read
Each connected bank feed and the accounting system are polled on schedule. Statements, wire confirmations, and invoice updates all land in a single canonical event log. One source of truth for what happened, when, and where it came from.
Deterministic Python · one log, many sources
2 · Match
Incoming wires match against open invoices by amount, customer, and recent reference. Clean matches auto-post to the accounting system. Ambiguous matches surface in a queue with full context attached for human review.
FIFO on multi-match · uncertainty flagged, never silent
3 · Follow up
Open invoices past their grace window get a single tracked follow-up, drafted by the runtime and reviewed before send. No duplicate outreach across systems, no customer hearing about the same invoice twice.
One trail per invoice · human approves every send
4 · Reconcile
Every action, whether a match, a follow-up, or a post, writes to the same append-only log. The cash position on the dashboard is the truth, traceable line by line back to the source event that produced it.
Append-only state · every line traceable
What you give it, what you get back.
You give it
- API or email access to each of your bank feeds (Gmail statements, Wise, Revolut, BT, or whatever stack you actually run)
- API access to your cloud accounting system (Zoho Books, Xero, QuickBooks Online, NetSuite, Sage Intacct)
- A Slack workspace with a finance notifications channel
- Your customer master + open-invoice register
You get back
- One AR runtime that replaces duplicate dunning + reconciliation processes with a single cycle
- Real-time DSO and cash-position visibility, refreshed on every event
- One follow-up trail per invoice, with full customer history attached
- An append-only audit log that traces every match, follow-up, and post back to its source event
This blueprint fits when…
You are a mid-market SaaS business on subscription, net-30 terms, with one AR lead carrying a few hundred active invoices by hand.
Your AR loop sprawls across an AR system, a CRM, a CSM tool, an accounting ledger, a bank, plus Slack and a spreadsheet, with no single log that ties them together.
Your team duplicates work between an email-driven follow-up process and the accounting ledger, so the same customer gets two trails and two reconciliations.
You watch DSO as a number, and you would rather own the runtime that moves it than rent a workflow platform that configures it for you.
You run an enterprise treasury and a full AR organization. This runtime is built to give one AR lead more reach, not to run a department.
Your billing is transactional B2C with thousands of low-value invoices. The cadence assumes named customers, named billing contacts, and account ownership.
There is no AR owner on your side. We give a capable operator more reach; we do not replace a function that nobody runs today.
Questions you’re probably asking.
It is a different category. A workflow platform configures orchestration inside the vendor's tenant and hands you back a screen to manage it. The runtime lives on their infrastructure; the configuration lives on their surface; your exit is a re-implementation. This is the opposite shape. Plain code in your git repository, running on a schedule in your VM, with adapters for your specific stack. The runtime is yours from the first day, the same model HKR runs internally, ported to your environment.
Effectively nothing. The repository is yours from the first day of the engagement. If you decide to stop, you clone the repo to a different VM, rotate the credentials, and keep running. No re-implementation, no platform unwind, no data migration. Our team stops operating it; you either operate it yourselves or hand it to a different team. That is the entire exit story, and it is the same exit option HKR has on its own runtime.
Different category, different purchase. The AR cloud incumbents sell software that runs on their infrastructure, in their tenant, with long deployments and enterprise contracts. We ship a runtime that runs on your infrastructure, in your VM, operated by an HKR team against the same task definitions HKR runs on its own AR. They sell their product. We give you the version of ours that we run on ourselves, adapted to your stack. If you want a heavily configured AR cloud with a long rollout, those vendors are the right call. If you want owned code that does the job, this is.
It cannot, by architecture. Every side-effecting action waits for a human approval in Slack before it executes. An escalation, a suspend, a write-off, none of them land without a person confirming in the thread. The runtime proposes, the operator confirms, the action records. When a match is ambiguous, the runtime flags the ambiguity with full context rather than guessing. Wrong matches stop at the human layer, the same way they stop at the human layer for HKR.
The runtime executes inside a VM in your security perimeter, so your existing controls, audit envelope, and data-residency rules all extend to it because the VM is yours. We do not hold your production credentials. They live as environment variables in infrastructure you control and are read only by the scripts that make the API calls, never by the language model. If your auditor asks where the code runs, the answer is in your VM, in your region, under your access policy. There is no shared tenant.
The runtime keeps running. We staff a named team with a documented rotation policy, and the runbook for every task lives in the repo alongside the code. The agent code does not depend on a specific operator, on our side or yours. If your AR lead changes seats, the code does not move. If our team rotates, the code does not move. The runtime is resilient to staffing because the runtime is yours.
You do. Your model provider key, your bill, capped at a ceiling you set. The model usage is a line item on your own cloud account, not an opaque markup on an invoice from us, and we set cost-ceiling alerts so you see usage before it moves. We share the math up front, scoped against your invoice volume, before the engagement starts.
The runtime does not ship a screen of its own. Slack is where the work happens: every confirmation, every escalation, every weekly summary lands there. A spreadsheet holds the canonical data: every invoice state, every aging snapshot, every wire match. Your existing visual tool sits on top of the sheet for the charts. Orchestration and visualization are different problems. We solve the orchestration problem and let the tools you already have do the visualization.
Want this on your accounts receivable?
HKR runs its own owned-AR runtime in production every day. That runtime is Jamie, our internal CFO agent. The version on this page is the one that runs on your data, adapted to your stack; we have not deployed it for you yet. If you collect across multiple banks and an accounting system, we can scope it for your operation in a 30-minute call.