Build vs Buy AR Automation: What It Costs to Build Collections In-House in 2026

You can build a working AR collections loop in a few weeks, and getting to a system that survives real volume takes roughly a year of senior engineering followed by permanent maintenance. Monk is an AI-native invoice-to-cash platform that runs collections, portal submission and cash application as one system, and the honest comparison sets a licence fee against a standing engineering commitment rather than against a one-off project budget. For most teams AR automation is infrastructure they depend on rather than a product they sell, so the question is whether you want to be in the business of building it and then continuing to run it. For a minority of teams, building is the right answer, and this guide tries to make that case properly rather than dismissing it.

The decision usually arrives in a specific form. Someone on the finance team is spending most of a week each month chasing invoices, an engineer says the reminder part looks like a fortnight of work, and the reminder part is a fortnight of work. What follows is everything that sits behind the reminder, what building buys you that no vendor can, and a way of costing the choice over three years rather than one.

What does build vs buy mean for AR automation?

Build means your engineers own the system that chases invoices, reads replies, resolves exceptions and applies cash. Buy means you run that on a platform built for it.

The line is less clean than it sounds, because almost nobody builds everything. A team that buys still writes integration glue, owns its data model and configures the policy governing which customers get chased. A team that builds starts from a model provider, an email service and a payment processor, so it is assembling components rather than writing them from scratch. The useful question is where you draw the boundary and who is on call when what sits behind it breaks at month end.

It helps to separate the three layers. The policy layer is your credit and collections rules, which are yours in both cases. The workflow layer is scheduling, targeting, escalation, state and audit. The integration layer is the ERP, the CRM, the payment processor, email deliverability and the portals. Buying replaces the middle and bottom layers. Building means owning all three, including the two that change without warning because someone else changed an API.

What do you get by building that you cannot buy?

Three real advantages, and they are worth stating plainly before the costs.

The first is exact fit. A platform encodes a general model of how invoicing and collections work. If your business does something unusual, usage billing reconciled against a metering service, milestone billing tied to site inspections, revenue shared with partners before invoicing, then a general model will need bending and the bending shows. A system you write follows your process precisely, and the value of that grows with how far your process sits from the norm.

The second is cost shape. Licence pricing generally scales with seats, invoice volume or receivables under management, which means the cost of the system rises with your success. An internal system has a large fixed cost and a small marginal one, so a business with very high invoice counts and thin margins per invoice can reach a point where owning the software is cheaper than renting it. That crossover is real, and it is worth modelling rather than assuming.

The third is control of data and behaviour. Everything sits inside your perimeter, under your retention policy, queryable by your analysts, with no vendor between you and your own remittance history. If you are building products on top of that data, or if a regulator or a large customer constrains where financial records may sit, that control can outweigh everything else. There is a fourth, less tangible benefit: the team that builds it comes to understand your cash cycle in detail, and that understanding tends to improve the process itself.

What is in the full build scope?

The reminder engine is the easy part and the smallest part. Everything downstream of a customer replying is where the year goes.

Inbound reply classification comes first. Replies are not answers to your question. They are out-of-office notices, forwards to a shared AP mailbox, requests for a copy invoice, disputes about a line item, promises to pay on a date, remittance advice with no invoice numbers, and bounce messages from a contact who left. Each needs a class, a confidence threshold, a handler and a route to a human when confidence is low. Deliverability sits alongside it: sending financial email at volume from your own domain means SPF, DKIM and DMARC alignment, warmed sending domains, suppression handling and reputation monitoring, because a collections programme that lands in spam is worse than none.

Portal submission is the largest single item. Across the receivables Monk manages, 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice. Each portal has its own format, PO matching rules, error codes and login flow, so this is browser automation at scale rather than an API integration, and it stays operationally intensive after launch because portals change their specs and customers move between them. Cash application is the next: matching payments to invoices when the remittance is a PDF, the payment is a lump sum covering nineteen invoices, the amount is short by a freight charge, and the reference field contains a purchase order number rather than an invoice number.

Then the parts nobody scopes. State management, because an invoice moves through a lifecycle with branching paths, paused for a promise, escalated to a person, reopened after a bounce, and the rules for valid transitions accumulate for as long as the system exists. Orchestration, meaning who is contacted, when, in what order and in what tone, which needs a configurable rules engine rather than a prompt and tends to be rewritten several times after launch. An append-only audit trail, because disputes and downstream logic depend on its integrity. And maintenance, which is not a phase: ERP APIs version, portals redesign, model providers deprecate endpoints, and a quiet quarter of no changes is a quarter of accumulating drift. The full list of what breaks is in the AR automation edge cases teams underestimate, and the specific limits of the model-first approach are in why an LLM alone is not collections automation.

What does building cost over three years?

Cost it as headcount you keep, rather than as a project you finish.

A production build needs a senior backend engineer who owns state and orchestration, an integrations engineer who owns the ERP, payments and portal connections, and part of a designer and a product manager to make the internal tool usable by the finance team. Call it two to three engineers for the first year. The mistake is assuming that number falls to zero afterwards. It falls to roughly one engineer of standing capacity, spread across maintenance, portal changes, new ERP versions, model updates and the feature requests that follow once finance starts relying on the tool. Over three years that is a multi-engineer commitment, plus infrastructure, logging, monitoring and a model bill that scales with invoice volume.

Opportunity cost is the larger figure and the one that rarely appears in the paper. Those engineers are not building the thing customers pay you for. They also become the only people who understand a system your finance team now depends on, which makes them difficult to reassign and expensive to lose. If your product roadmap is capacity constrained, the internal AR tool is competing against revenue work every sprint, and it will keep losing until the month it breaks, at which point it wins for a week.

There is a governance cost too. An internal system needs an owner, a runbook, an on-call path for month end, and a plan for what finance does when it is down on the last working day of the quarter. None of that is difficult, and all of it is permanent.

What about security and compliance?

AR automation touches more sensitive data than it first appears, and the obligations transfer to you along with the code.

Billing contacts, payment terms, bank details and invoice amounts are all in scope, so the system has to meet your data handling standards and your customers'. Submitting to portals means storing and rotating credentials and MFA tokens for other companies' systems. Disputes require a complete, append-only audit trail by design, because downstream logic and any later legal position depend on its integrity. Sending financial email at volume is an attack surface for spoofing and invoice fraud, and the countermeasures are yours to design.

If you sell to enterprises, expect your customers to ask whether your AR system falls inside your compliance posture. It does, which means it appears in your SOC 2 scope, your penetration tests and your vendor questionnaires. That is manageable for a team that already runs regulated infrastructure and a meaningful surprise for a team that does not.

When should you build, and when should you buy?

Build when your billing model is unusual, you have platform capacity to spare, or a regulatory constraint forces it. Buy when collections is critical infrastructure that is not part of what you sell.

The strongest build case has three parts present at once. Your billing model is unusual enough that no platform maps onto it without distortion. You have an existing platform team with real capacity, ideally one that already owns similar integration-heavy internal systems. And the work is close enough to your product that the engineers doing it learn something you can sell. Add a fourth situation that overrides the rest: a regulatory or contractual constraint on where financial data may be processed that no vendor can satisfy. If all of that is true, building is a defensible decision and you should make it deliberately rather than by drift.

The hybrid position deserves more attention than it gets, because it is where most sophisticated teams land. Buy the platform for the parts that are the same everywhere, meaning portal submission, reply handling, deliverability, cash application matching and the audit trail, then build the thin layer that is specific to you: the pricing or metering logic that produces the invoice, the internal approval workflow, the reporting your board wants, the write-back into your own data warehouse. That layer is weeks of work rather than years, it sits behind an API, and it does not need maintaining every time a portal changes its login page.

How does Monk compare?

Monk is a purpose-built invoice-to-cash system of record, from invoice to applied cash, that most teams take live in less than one week.

It resolves 90% of collections with zero human intervention, reduces DSO by 40% on average, and saves finance teams 26 hours a month. Julia, Monk's AI agent for Intelligent Collections, ingests the context of each conversation and reaches a 24% higher response rate than standard dunning. Cash application matches at 80% automatically, rising to 95% with suggested matching rules. The 92% of enterprise invoices that must go through a vendor portal or network are handled inside the same flow, and 39% of cash flow slowdown traces back to edge cases of that kind, which is the work an internal build inherits in full.

Monk is SOC 2 Type II compliant, manages $2B+ in accounts receivable, and integrates with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, alongside Slack, Gmail, Docusign, Anrok, Plaid and Mercury. Customers see results in their first month. See it in Monk's collections automation and ERP integrations. Monk handles the 600-plus procurement portals that manual teams dread and files 87% of those submissions autonomously. Monk has $2B+ in accounts receivable under management, including for Profound and ElevenLabs.

Where should you start?

Write the scope down before you estimate it, because most build decisions are made against a mental model that stops at the reminder engine.

List the components: scheduling and targeting, reply classification, deliverability and domain reputation, dispute capture, promise tracking, portal submission by portal, cash application matching, unapplied cash handling, audit trail, reporting, admin interface, and the on-call path for month end. Put a name and a week count next to each. Then classify every inbound message in last month's collections inbox by type, counting how many a classifier of your own would have handled without a person. That count measures the gap between the demo you imagine and the system you would run.

Finish with the three year view: engineers committed in year one, standing capacity in years two and three, what those people would otherwise ship, and the date finance would see the first result under each option. If the numbers point to building, build with your eyes open and start with the hybrid boundary rather than the whole scope. If they point the other way, book a demo and test the platform against the same list you wrote.

Frequently Asked Questions

Is it cheaper to build or buy AR automation?

Building looks cheaper until it is costed over three years rather than as a one-off project. A production system takes roughly a year of senior engineering, then about one engineer of standing capacity for maintenance, portal changes and ERP versions, plus infrastructure and a model bill that scales with volume. Buying replaces that with a fee and a go-live in less than one week.

How long does it take to build AR collections in-house?

A basic follow-up loop works in weeks. A production system that handles disputes, partial payments, portals and cash application takes six to twelve months of focused work with no rework, and edge case handling has no fixed endpoint.

What breaks first in a home-built AR system?

The exceptions. Partial payments, remittance without invoice numbers, deductions, out-of-office replies, contacts who have left, and portal rejection codes discovered days later. Simple logic handles the happy path and routes everything else to a person, which recreates the manual process the build was meant to remove.

Why is portal submission so hard to build?

Most enterprise invoices route through procurement portals, each with its own format, PO rules, error codes and login flow, so it is browser automation at scale rather than an API integration. Portals change their specs and customers move between them, so the work does not end at launch. Across the receivables Monk manages, 92% of enterprise invoices must be submitted this way.

When is building the right decision?

When your billing model is unusual enough that a general platform would need distorting, when you have a platform team with genuine spare capacity, or when a regulatory or contractual constraint dictates where financial data is processed. A build chosen deliberately for one of those reasons tends to work, while one chosen because the reminder engine looked easy tends not to.

Can you buy a platform and still build part of it yourself?

Yes, and it is often the strongest answer. Buy the parts that are common to everyone, portal submission, reply handling, deliverability, cash application and audit, then build the thin layer specific to you: your pricing or metering logic, internal approvals, and the write-back to your warehouse. That layer is weeks of work, and it survives a portal changing its login page.

Does an in-house AR build raise compliance risk?

It moves the obligation to you. The system handles bank details, personal data and financial communications, so audit trails, credential rotation for portals, approval controls and SOC 2 scope become yours to design and defend. That is routine for a team already running regulated infrastructure and a real surprise for a team that is not.