Accounts Receivable Automation for Dynamics 365 Business Central

Business Central accounts receivable automation means putting a workflow layer on top of Dynamics 365 Business Central that handles what the ERP doesn't: prioritising which accounts to chase, sending and escalating reminders, tracking promises to pay, logging disputes, and giving managers a live view of collections activity -- while Business Central itself stays the untouched source of record for invoices and payments.

Out of the box, Business Central gives you reminder terms and finance charge memos -- functional, but batch-driven and blind to everything that happens after the reminder goes out. The actual collections process at most mid-market companies looks the same regardless of ERP: an aged debtors export lands in Excel, someone works down it from memory, the customer conversations live in personal inboxes, and nobody can answer "what was promised, by whom, and did it arrive?" without asking the one person who knows.

We've now built AR platforms for two Business Central companies with very different ledgers -- a US insurance services firm with $11.8M open across 7,700+ invoices, and a Norwegian equipment rental group with €7.6M open and a one-person AR team. The gap they were closing was identical. The rest of this guide is the decision framework and the architecture that came out of those builds.

There are three realistic routes, and the right one depends on how standard your payer model is and where your data is allowed to live.

The honest rule of thumb: if you have one AP contact per customer and a simple reminder ladder, buy something -- an add-on or SMB SaaS tool will be live faster and we'd say so in an assessment. The custom route wins when the process itself is non-standard. Our insurance client chases ~2,500 individual claims adjusters spread across 1,200 carrier customers, with escalation logic tied to their own org structure. No subscription product models that. The build cost less than enterprise AR licences for a team their size -- and matched the real process instead of flattening it.

Both builds follow one non-negotiable principle: Business Central is read-only. The platform never writes to the ERP. Here's the pattern:

• Data out through the warehouse, not the API. A daily sync reads open AR from an Azure Synapse view in one build, and from the Microsoft Fabric Gold SQL endpoint (after the client's own pipeline refresh) in the other. Both land the data in the platform's own Azure PostgreSQL database. If you already run Synapse or Fabric against Business Central, the hard part of this exists.
• Activity data stays in the platform. Everything collections work creates -- call logs, notes, promises to pay, disputes, tasks, sent emails -- is written to the platform's database, never back to BC. Finance keeps a clean ledger; the platform accumulates the structured activity history that BC never had.
• Email through Microsoft Graph. Dunning emails and statements send from the company's own mailboxes via Graph, using a create-draft-then-send pattern so every message lands in a complete, threaded ledger. Replies are read from the same shared mailbox -- the agent answers inside existing threads instead of spraying new ones.
• Entra ID sign-on, managed identities, Container Apps. Five roles in the insurance build -- sales reps see only their own accounts; managers and executives see their tier of the escalation pyramid. No new passwords, no connection-string secrets, and deploys ship automatically from a push to main.

Why not write reminders back into BC's own reminder module? Because the moment automation can write to the ERP, every bug is a books problem and every auditor question gets harder. Read-only isn't a limitation -- it's the property that makes finance teams comfortable switching the automation on.

Strip away the vendor language and an AR platform earns its keep in five places. This is what runs in production across the two builds:

Aged debtors reports sort by days overdue, which quietly prioritises a $500 invoice at 90 days over a $50,000 one at 60. The insurance build replaces that with a balance-weighted days-overdue score recalculated daily for every payer -- so exposure, not just age, drives the queue -- feeding four escalation tiers up to executive level. The Norwegian build scores each account Low/Medium/High from balance, days overdue, payment history, dispute state, promises to pay and factoring status. Either way, the point is the same: the queue orders itself every morning, and nobody starts the day deciding whom to chase.

Routine accounts get grouped outreach tasks on a twice-monthly cadence. Broken promises and seriously aged invoices generate weekly tasks. Crossing a risk threshold escalates immediately to the right tier -- AR analyst, account rep or executive. Tasks close themselves when the invoice is paid or disputed, so the queue never fills with dead work. In the rental build the outbound ladder is aging-driven: reminder the day after due, overdue notice at seven days, final notice at fifteen, then escalation.

This is the single highest-value feature in both builds, and no spreadsheet does it well. Every promise gets a date and an amount, auto-creates a follow-up task on the promise date, and fulfilment is measured -- including milestone tracking for payment plans. Broken promises surface automatically after seven days instead of whenever someone remembers. Managers finally see promise-fulfilment rates per customer and per collector, off real data.

Templates escalate from friendly reminder to formal notice, personalised from ledger data, with the full trail logged against the account. Just as important is when chasing stops: the moment a dispute opens, the cadence halts and a structured fact-finding workflow takes over. In the Norwegian build, if a case eventually goes to the external collection agency, the platform auto-generates a complete dispute brief -- the context that previously lived only in the account manager's head.

Because every call, promise, dispute and email is structured data, management reporting stops being an assembly job: collector productivity, promise fulfilment, aging trends, and a daily snapshot history that makes the trend line real rather than reconstructed. The insurance firm's executive team sees its escalation tier -- around $3M of the ledger -- without asking anyone for a spreadsheet.

The Norwegian build goes a step further than workflow automation: an AI collections agent reads the ledger every morning and drafts the correct chase email for each account -- in Norwegian, staged to the right point in the cadence. A single run drafted 162 correctly-staged chase emails across 1,080 open invoices. On the inbound side it polls the AR mailbox every ten minutes and classifies each customer reply into one of twelve intents -- full or partial dispute, promise to pay, "already paid", query, legal threat, bankruptcy and more -- then drafts the response or action.

What makes this safe rather than reckless is the guardrail design:

• Human approval on every send. The agent produces drafts in an approval queue, never autonomous sends. Reviewers edit before releasing, and cases group by contact so one approval shows everything open for that customer.
• No invented numbers. Every figure in every draft comes from ledger data. The LLM (Anthropic's Claude, in a real tool-calling loop) gathers invoice details and conversation history before making a single structured decision.
• Hard stops. Legal threats and bankruptcy mentions route straight to a human. "Already paid" claims are verified against the ledger before anything closes. No chasing while a dispute is open.
• Tested before trusted. The agent passed a 23-scenario harness covering the full outbound cadence and every inbound intent before go-live.

The sequencing lesson from both projects: get the deterministic automation right first. The insurance build deliberately shipped without an LLM -- risk scoring an auditor can follow, rules the team can edit -- and in doing so produced the clean, structured activity dataset that makes an AI layer a straightforward next step instead of a leap of faith.

The before/after in both companies is the same shape. Collections moves from inbox archaeology to a managed pipeline: every payer has an owner, a risk tier and a next action. The AR controller at the rental group no longer writes chase emails from scratch or keeps the state of 300 accounts in her head -- she reviews and releases pre-drafted, correctly-timed emails. And because that group borrows against receivables through factoring, faster and more consistent chasing translates directly into working capital headroom.

Dispute context survives handoffs. Escalations arrive at the collection agency with a complete brief. Promises are tracked and followed up mechanically. None of this required touching Business Central.

If you run Business Central and your collections still live in Excel and Outlook, start by answering three questions: How non-standard is your payer model? Where is your BC data already consolidated (Synapse, Fabric, neither)? And how documented are your escalation rules -- do they exist anywhere outside one person's head?

Those three answers determine build-vs-buy, timeline and sequencing -- and they're exactly what our AI readiness assessment establishes. Both platforms described here went from kickoff to production in weeks, not months, because they reused infrastructure the clients already had. If you want to see the builds in detail first: the $11.8M collections platform and the AI collections agent on Fabric. For the broader pattern beyond receivables, see ERP finance automation.