Accounts Receivable in D365 F&O: From Customer Setup to Cash in the Bank

The full customer-to-cash lifecycle — what happens, why it happens that way, and how to set it up so your AR team can actually do their job without fighting the system every day.

AP vs. AR: Same Logic, Different Stakes

If you read the AP post in this series, a lot of what you’re about to read will feel familiar in structure — there’s a customer master that drives behavior, a transaction lifecycle to walk through, a set of posting profiles controlling the accounting, and a collection of mistakes that show up consistently in implementations. The architecture is the same.

But the stakes are different, and it’s worth saying that plainly before we get into the details. In AP, you control the timing. An invoice sits in the system until you decide to pay it. In AR, your customers control the timing — and your job is to manage that reality through good setup, clean invoicing, and a collections process that actually has teeth. Every configuration decision in AR either makes that job easier or harder.

The other thing I want to name upfront: AR in D365 F&O is genuinely feature-rich. The collections workspace, the customer aging, the interest and fee automation, the credit limit controls — there is real capability here that most organizations use only a fraction of. This post covers the full lifecycle from setup through cash application. We’ll touch on the collections tools, but collections management in F&O deserves its own post — and it will get one.

Customer Master Setup — The Foundation Everything Else Relies On

Just like vendor records in AP, the customer master record in D365 F&O is not just contact information. It carries the configuration that controls how invoices are generated, how payments are applied, what credit limits are enforced, and how collections activity is tracked. Get this right during setup and the rest of the AR process flows naturally. Rush through it during data migration and you will be untangling customer record problems for the first six months of go-live.

01 Customer Groups — Same Concept, Equally Important

Drives posting behavior and shared defaults

Every customer belongs to a customer group, and that group assignment determines which AR summary account their balances land in on the general ledger — exactly as vendor groups do on the AP side. Domestic customers, international customers, intercompany customers, government customers, and retail customers may all need to post to different AR accounts, be subject to different payment terms, and follow different tax rules.

Customer groups also control default posting profiles, settlement priorities, and tax group inheritance. Moving a customer from one group to another after transactions have posted is possible but consequential — the historical transactions don’t repost, so your AR reporting can show split balances across groups for the same customer if changes are made carelessly.

Design This Before Migration

Define your customer group structure in your design workshop — not during the data migration sprint
Intercompany customers must be in a separate group if you need intercompany AR to post to a distinct account for consolidation
Government customers often have different payment term norms and tax exemptions — consider whether they warrant their own group

02 Payment Terms and Methods

The contract terms that drive your cash flow expectations

Payment terms on the customer record work exactly the same way as on the vendor side — they define when invoices are due and whether early payment discounts apply. Net 30, Net 60, 2/10 Net 30. These drive the due date on every invoice, the aging buckets in your AR aging report, and the collections activities the system will trigger when invoices go overdue.

This sounds straightforward, and it mostly is — with one gotcha. If your organization has negotiated different payment terms with different customers, those terms need to be on the customer record accurately and specifically. A customer who negotiated Net 45 but has Net 30 in the system will show up as overdue two weeks before they technically are. Your collections team reaches out, the customer (correctly) says they’re not late yet, and you’ve done nothing but irritate someone who was going to pay you anyway. Small data quality issue, real relationship consequence.

Worth Verifying

Review payment terms against your actual customer contracts during data migration — don’t assume the legacy system has them right
Early payment discount terms need to be set up in the system’s payment terms configuration before they can be assigned to customers — don’t wait until a customer actually takes a discount to discover the term doesn’t exist yet
Payment method on the customer record defaults onto payment journals for that customer — set it so cash application doesn’t require a manual selection every time

03 Credit Limits

The Control Your Sales Team Will Push Back On And the one your AR team absolutely needs

D365 F&O supports customer credit limits that the system can enforce at the time a sales order is entered. When a customer’s outstanding AR balance plus their new order would exceed their credit limit, the system can warn the order entry team, block the order entirely, or route it for credit manager approval — depending on how you configure the credit management rules.

This is a genuine capability that many organizations underuse because the initial setup conversation is uncomfortable. Sales doesn’t want orders blocked. Credit management wants the control. Finance needs the data. The implementation is the right moment to have that conversation and reach an agreement on how aggressively the system should enforce credit limits — because configuring it reactively, after a large uncollectable balance has already developed, is a less pleasant conversation than having the policy discussion upfront.

Credit limits in F&O can be set at the customer level and can factor in not just open invoices but also unposted sales orders and confirmed POs — giving you a forward-looking picture of exposure, not just a backward-looking one. That is materially more useful than a credit limit that only considers posted AR.

Implementation Decisions to Make

Hard block vs. soft warning vs. approval routing — agree on this before configuration, not after the first blocked order causes friction
Who has authority to override a credit limit hold? That approval path needs to be in the workflow
Credit limits of zero on every customer (the lazy default) means the control does nothing — audit your migrated customers and set real limits

04 Sales Tax Groups and Exemptions

The detail that becomes urgent when it was skipped

The customer’s sales tax group — combined with the item’s item sales tax group — is what D365 F&O uses to determine whether sales tax applies to a given transaction and at what rate. Tax-exempt customers need their exemption status on their record, along with the exemption certificate number, before the first invoice is generated. Tax-exempt customers who get charged sales tax because their record wasn’t set up correctly are going to let you know about it — and the credit memo process to reverse incorrectly applied tax is a headache nobody needs.

This is also the area where multi-state or multi-jurisdiction complexity shows up. If your organization sells to customers across multiple states with different tax rates and rules — and you are required to collect and remit sales tax in those states — your sales tax configuration needs to handle that correctly at the time of invoicing, not retroactively. That is a detailed configuration conversation that involves your tax team, and it needs to happen during implementation, not after your first quarterly tax filing.

Don’t Skip This

Document tax-exempt customers and their exemption certificate numbers before migration — this is a legal compliance matter, not just a setup preference
Involve your tax team in sales tax group configuration — this is one of the areas where implementation consultants should defer to your tax expertise
Test tax calculations with real customer and item combinations before go-live — don’t assume the configuration is right until you’ve seen the output

05 Financial Dimensions and Delivery Defaults

The automation that saves your team thousands of keystrokes

Default financial dimensions on the customer record flow through to every sales order and invoice posted to that customer — just as they do on the vendor side in AP. If a particular customer’s revenue always belongs to a specific region, sales channel, or business unit, set those dimension defaults on the customer record and the system handles the coding automatically. Your AR team focuses on accuracy, not data entry.

Customer records also carry delivery defaults — preferred carrier, delivery terms, delivery address. These flow onto sales orders automatically and eliminate the manual entry step for routine shipments. Small thing, but multiply it across hundreds of orders per week and it adds up to meaningful time savings and meaningfully fewer errors.

Automate What You Can

Assign default financial dimensions during customer data migration — not as a post-go-live enhancement
For customers with multiple ship-to addresses, set up those addresses on the customer record so order entry can select rather than retype
Delivery terms (FOB, CIF, etc.) on the customer record can affect when revenue is recognized — confirm with Finance that defaults are set correctly for your revenue recognition policy

The AR Lifecycle — Order to Cash

Here’s the full arc. Not every organization uses every step — some don’t use sales orders, some invoice directly, some have highly automated cash application. But understanding the complete lifecycle helps you know what role each step plays and what breaks when a step is skipped or misconfigured.

Walking the Lifecycle

SO: The Sales Order — The Revenue Commitment

Where the customer-to-cash process begins

The sales order in D365 F&O is your organization’s commitment to deliver specific goods or services to a specific customer at a specific price. It’s the document that drives picking, shipping, invoicing, and — ultimately — the AR balance that your collections team manages. Everything downstream inherits from the sales order, which is why sales order setup and item pricing configuration matter so much.

Prices on sales orders can come from a few places in F&O: manually entered, pulled from a trade agreement, or calculated from a price group assigned to the customer. Trade agreements are one of F&O’s more powerful pricing tools — they allow you to define customer-specific prices, quantity break pricing, and promotional pricing with effective date ranges, all of which apply automatically when a sales order is created for a qualifying customer and item combination. Setting these up correctly eliminates a lot of manual price override activity and the pricing disputes that come with it.

Sales orders also support delivery schedules — where a single order commits to multiple delivery dates and quantities — and direct deliveries from vendor to customer. These are scenarios worth discussing with your sales and operations teams during implementation discovery, because they affect how the sales order is structured and how invoicing is triggered.

Sales Order Setup Considerations

Trade agreements require their own configuration and testing — if your business has complex or customer-specific pricing, build and test trade agreements before go-live, not after
Sales order confirmation sends a formal document to the customer — make sure your document templates and email setup are configured before order entry goes live
If you use credit limit checking at order entry, test that the blocking and approval routing works as intended during UAT, with real customer scenarios

SHP: Picking, Packing, and Shipping — When the Goods Actually Leave

The operational step that triggers revenue recognition

For product-based businesses, the shipping step in D365 F&O is where things get real in two important ways. First, inventory is relieved — the goods leave your on-hand count and their cost moves toward COGS. Second, depending on your delivery terms and revenue recognition policy, this is often the moment when revenue can be recognized. Ship-and-bill businesses typically invoice immediately after shipment, which means the timing of the packing slip posting has a direct relationship to when AR is created and when revenue hits the P&L.

The packing slip in F&O is the document that confirms physical shipment. Posting the packing slip relieves inventory and creates the cost accrual that waits for the invoice to be generated. It does not yet create the AR entry — that happens when the invoice posts. For audit purposes, the packing slip is the evidence that goods were delivered, and it’s what supports the invoice in a dispute or a revenue recognition review.

Things That Matter Here

Delivery terms on the sales order determine when title transfers — FOB shipping point means risk transfers when goods leave your dock; FOB destination means when they arrive at the customer’s. Your revenue recognition policy should align with your delivery terms
Partial shipments are supported — you can ship 60 of 100 ordered units and invoice for what shipped, with the remainder staying open on the sales order
Packing slips posted in error can be reversed before invoicing — but the window closes once the invoice is generated

INV: Invoice Generation — Creating the Receivable

The moment AR is born on your balance sheet

When a sales order invoice is posted in D365 F&O, several things happen simultaneously: the AR summary account is debited (the customer now owes you money), revenue is credited to the appropriate income accounts per your posting profile, COGS is debited and inventory is credited if goods were shipped, and a customer-facing invoice document is generated. All of that from a single post action — which is why the posting profile configuration from earlier in this series matters so much. The accounts that get hit are determined entirely by the configuration that was set up before the first invoice ever ran.

F&O supports both individual invoice posting and batch invoice posting. For businesses with high invoice volume, batch posting — where you post all invoices for a date range in a single run — is far more efficient than posting one at a time. Batch posting can also be scheduled to run automatically during off-peak hours, so your AR team arrives in the morning to find the previous day’s orders already invoiced. That is a nice thing to arrive to.

Free text invoices are a separate invoice type in F&O — used for charges that don’t originate from a sales order. Consulting fees, rent receivable, miscellaneous charges. These are entered directly in the AR module without a sales order, and they require manual account coding because there’s no underlying order to pull the GL distribution from. They need dimension coding attention, exactly like non-PO invoices do on the AP side.

Invoice Generation Details

Invoice date and delivery date are separate — delivery date drives revenue recognition timing; invoice date drives payment due date. Get both right
Invoice print and email configuration needs to be set up and tested before go-live — the first invoice your customer receives from the new system is a first impression
Free text invoice dimension coding is manual — build it into your AR procedures and train your team explicitly

COL: Customer Aging and Collections — Managing What’s Owed

The work between invoice and payment that most systems make harder than it needs to be

Once an invoice is posted and sitting in a customer’s AR balance, the clock starts. D365 F&O’s aging report shows you where every customer balance sits relative to its due date — current, 1-30 days past due, 31-60 days, 61-90 days, 90+ days. The aging buckets are configurable, and they should reflect the buckets your collections process and your Controller actually use for reporting and review.

F&O’s Collections workspace is genuinely one of the better-designed features in the AR module. It gives your collections team a prioritized worklist of customers with overdue balances, shows the full aging picture and transaction detail for each customer, and allows collections activities — phone calls, emails, notes, promises to pay — to be logged directly against the customer record. This creates a collections history that is invaluable when you need to document that you pursued a balance before writing it off, and it eliminates the spreadsheet-based collections tracking that most organizations default to when the system isn’t configured to handle it.

Interest and fee automation is another underused capability. D365 F&O can automatically calculate and post interest charges on overdue balances based on interest codes you define — daily rate, monthly rate, fixed fee, or combinations. When a customer receives an interest charge on their statement, it is a clear signal that your organization tracks and enforces payment terms, which often has a more positive effect on payment behavior than a phone call alone.

Collections Setup to Do Proactively

Configure aging period definitions to match how your leadership reviews AR — if leadership reviews in 30/60/90 buckets, your system aging should match
Set up the Collections workspace customer pool assignments so each collector sees their customer portfolio, not the entire AR aging
If you intend to charge interest, configure interest codes and customer interest profiles during implementation — not the first time a customer goes 90 days overdue

The Collections Activity Timeline — What Good Looks Like

Let me show you what a structured, system-supported collections process actually looks like in practice — the sequence of activities that D365 F&O can support and log for a customer who isn’t paying on time. This isn’t the only way to run collections, but it illustrates how the system’s capability can replace the spreadsheet and the sticky note.

Invoice Due Date
Invoice Due — Enters Aging

The invoice hits Day 1 past due. In the Collections workspace, it appears on the collector’s worklist. At this point, most organizations don’t act immediately — but the system is tracking.

Day 5–10 Overdue
First Dunning Letter / Statement

F&O can generate dunning letters automatically based on dunning rules you configure — a polite first reminder that an invoice is past due. The dunning history is logged on the customer record so you know exactly what was sent and when.

Day 15–20 Overdue
Collections Call — Activity Logged

Your collector makes contact. In the Collections workspace, they log the call as a collections activity — date, summary, outcome, promise-to-pay date if applicable. That log becomes the record of your collection effort, which matters if this eventually goes to write-off or legal.

Promise to Pay Logged
Promise-to-Pay Date Recorded

If the customer commits to a payment date, that promise can be logged in the Collections workspace. The system tracks whether the payment actually arrives by that date — and if it doesn’t, it surfaces the broken promise automatically on the collector’s next review.

Day 45–60 Overdue
Escalation — Credit Hold

For customers who haven’t responded or paid, a credit hold can be applied — blocking new sales orders until the balance is resolved. This is a significant step and usually requires credit manager authorization, but having it available and configured means you have a lever to pull.

90+ Days
Write-Off Consideration

After exhausting collections efforts, a balance that’s unlikely to be collected is written off to bad debt expense. In F&O, write-offs post to the bad debt account configured in your AR posting profile and remove the balance from the customer’s AR. The collections activity log is your documentation that you pursued the balance before writing it off.

Cash Application — The Step That Closes the Loop

Cash application is the process of matching incoming customer payments to the invoices they’re intended to pay. It sounds straightforward. In practice, it’s one of the most operationally variable parts of AR — because customers don’t always pay cleanly. They pay multiple invoices in one check. They take deductions. They pay an approximate amount. They pay the wrong invoice. They don’t tell you what they’re paying. Cash application is where all of that gets sorted out.

The Cash Application Process in D365 F&O

1. Payment Received — Record the Cash Receipt

The customer payment arrives — check, ACH, wire. It’s recorded in a customer payment journal, which debits the bank account and creates a temporary credit on the customer’s account. At this point the payment is recorded but not yet applied to specific invoices.

2. Settlement — Matching Payment to Invoice

The settlement step is where the cash receipt is matched against open invoices on the customer’s account. F&O allows manual settlement (your AR team selects which invoices this payment covers) or automatic settlement (the system applies the oldest invoices first or uses a priority rule you define). When a payment perfectly covers an invoice, it closes. When it partially covers an invoice, the invoice remains open for the remaining balance.

3. Handling Discounts and Deductions

If a customer takes a legitimate early payment discount, the discount is recorded at settlement — the difference between the invoice amount and the payment amount posts to the cash discount taken account from your AR posting profile. If a customer takes a deduction they’re not entitled to, that becomes a dispute to manage — which can be documented in the Collections workspace as a customer case.

4. Posting — Closing the Receivable

Once settlement is complete and the payment journal is posted, the customer’s AR balance decreases accordingly. Fully settled invoices disappear from the aging. Partially settled invoices remain open for the outstanding amount. The bank reconciliation will confirm the payment cleared your actual bank account, completing the loop from revenue recognition to cash receipt.

Credit Notes and Adjustments — When Things Need to Be Undone

No AR process runs without credit memos. A customer received damaged goods. A pricing error needs correction. A return comes in. Credit notes in D365 F&O can be generated in a few ways depending on the originating transaction, and understanding the right approach matters for keeping your AR subledger clean.

01 Sales Order Return / Credit

For product returns, the right approach is a return sales order — which creates the proper inventory receipt and reverses the original revenue and COGS entries correctly. This keeps your inventory accurate and your P&L clean. A standalone journal entry to reduce AR doesn’t reverse the inventory or COGS — which leaves your books out of balance in ways that only surface later.

02 Free Text Credit Note

For pricing adjustments, service credits, and non-inventory corrections, a free text credit note is the appropriate tool. It reduces the customer’s balance directly and posts to the accounts you specify. Like free text invoices, it requires manual dimension coding — build that into your procedure so credits don’t post with blank dimensions any more than original invoices do.

03 Invoice Correction

F&O supports invoice correction functionality that creates a reversal of the original invoice and a corrected replacement in a single process. This is cleaner than a manual credit memo plus a new invoice when the error is on the original invoice itself — it maintains the documentary trail and keeps the settlement history coherent.

04 Write-Off

When a balance is genuinely uncollectable, a write-off removes it from AR and posts the amount to bad debt expense. F&O’s write-off functionality handles the posting automatically to your configured bad debt account. Document your collection effort in the Collections workspace before writing off — that documentation protects you in an audit.

The Mistakes That Cost AR Teams the Most

Customer Records With No Credit Limits Set

A credit limit of zero in D365 F&O doesn’t mean “no credit extended” — in most default configurations it means the credit limit check is not enforced, which effectively means unlimited credit for every customer. Organizations that migrate customers with zero credit limits because nobody took the time to set them during implementation often discover the gap the hard way — when a customer with a long-overdue balance places and receives a large new order that extends the exposure further.

→ As part of customer data migration, assign credit limits that reflect your actual risk tolerance for each customer. Even rough limits — based on historical order volume or an agreed default by customer segment — are better than no limits at all. Your credit manager should own this review.

Unapplied Payments Aging in the Customer Account

This is the AR equivalent of the purchase accrual problem in AP. A payment comes in, gets recorded in the payment journal, gets posted — and then nobody settles it to the specific invoices. The customer’s account shows an unapplied credit. Their invoices stay technically open. The aging shows those invoices as outstanding even though the money is in the bank. Month after month, the list of unapplied credits grows, the aging becomes unreliable, and reconciling the AR subledger to the general ledger becomes increasingly complicated.

→ Make unapplied payment review a weekly procedure for your AR team. D365 F&O has a report specifically for this. Any payment that’s been sitting unapplied for more than a few days needs to be investigated and settled. It is a simple operational discipline that keeps the AR data clean.

Collections Activity That Lives in Spreadsheets Instead of the System

This is the most common AR implementation gap I see, and it’s usually not a configuration failure — it’s a training and adoption failure. The Collections workspace is set up. The capability is there. But the AR team is comfortable with the spreadsheet they’ve been using for years, and nobody invested the time to show them how the system’s collections tools actually work. So the spreadsheet lives alongside the system, and the two never reconcile, and the collections history that should be in the system isn’t — which means when a balance needs to be written off or escalated, there’s no documented evidence of collection effort.

→ Include Collections workspace training as a dedicated session in your AR team’s go-live preparation — not a slide in a general overview, but a hands-on walkthrough of how to log activities, set promise-to-pay dates, and generate dunning letters. The system can replace the spreadsheet entirely. But that replacement requires people to actually use it.

Returns Processed as Journal Entries Instead of Return Orders

When a customer returns product and the AR team handles it by simply posting a manual credit memo or journal entry to reduce the AR balance, the inventory never comes back. The COGS never reverses. The revenue reverses — but the cost doesn’t. Your gross margin takes a hit that doesn’t reflect economic reality. The inventory system doesn’t know the goods came back, so they’re not available to sell again or count on the next physical inventory. This is a process design problem masquerading as an accounting problem.

→ Train your AR and warehouse teams together on the return order process. A customer return should create a return sales order, which triggers a receiving process, which updates inventory, which reverses COGS correctly. This is a cross-functional workflow that requires both teams to understand their role. Define it, document it, and test it in UAT with real return scenarios before go-live.

Customer Statements That Are Never Sent

D365 F&O can generate and send customer account statements automatically — a list of all open invoices and their aging — on whatever cadence you configure. This is one of the simplest and most effective collections tools available, and it is consistently underused. Customers who receive regular statements know exactly what they owe and when it’s due. Customers who never receive statements are more likely to have aging invoices they’ve simply lost track of. The statement is not just a collections tool — it’s a customer service.

→ Configure customer statement generation and distribution as part of your AR module setup. Monthly statements to all customers, weekly for those in overdue status. Automate the distribution so it runs without your team manually initiating it. This is an hour of configuration that pays back continuously.

Dunning Letters That Go Out for Every Balance, Including Current Ones

The flip side of not using collections tools is using them indiscriminately. Dunning letter configurations that aren’t properly tuned can send collection notices to customers whose invoices aren’t actually past due — customers who paid on time, customers within their payment terms, or customers with a credit on their account that offsets the outstanding invoice. Sending a collections letter to a good-standing customer is a relationship problem and a credibility problem. It signals that your internal systems and your communications aren’t aligned.

→ Configure dunning rules carefully and test them with real customer scenarios before enabling automated distribution. Make sure the aging date logic, the minimum balance thresholds, and the customer exclusion rules are all tuned before dunning letters go live. Have your AR manager approve the first batch before they’re sent to customers.

Quick Reference: Do’s and Don’ts

✓ Do This

Define customer group structure before data migration begins
Set real credit limits on every customer record — not zero defaults
Verify payment terms against actual customer contracts during migration
Flag tax-exempt customers and load exemption certificates before go-live
Assign default financial dimensions on customer records during migration
Set up and test invoice email/print distribution before the first invoice posts
Configure aging period definitions to match how leadership reviews AR
Train your AR team on the Collections workspace — hands-on, dedicated session
Make unapplied payment review a weekly AR procedure
Handle product returns through return sales orders, not manual journal entries
Configure and test dunning letter rules before enabling automated distribution
Set up customer statement generation and automate the distribution schedule

✗ Don’t Do This

Migrate all customers to a single default group for migration convenience
Leave credit limits at zero and assume that means controls are in place
Skip sales tax exempt status setup and plan to correct it after go-live
Let collections activity continue to live in spreadsheets alongside the system
Allow unapplied payments to age without a regular review and settlement process
Process inventory returns as manual AR credit memos — use return orders
Send dunning letters without testing the customer and aging filter rules first
Ignore the Collections workspace because the team is used to spreadsheets
Assume the invoice template looks correct without testing the actual output
Configure free text invoices without requiring financial dimension coding
Skip customer statement setup because “our customers know what they owe”

From one recovering controller to another: AR is the module that most directly reflects the health of your customer relationships and the discipline of your revenue operations. A clean AR process — well-configured, well-trained, and actively managed — is one of the clearest signals of a finance team that knows what it’s doing. It shows in your DSO. It shows in your audit. It shows in how your customers talk about working with you.

The configuration details we covered today — credit limits, tax exemptions, settlement procedures, collections tools — none of them are exciting. But collectively they are the difference between an AR module that runs itself and one that requires constant manual intervention. Build it right and let the system do the work it was designed to do.

Up Next:

I’ve mentioned the Collections workspace a few times in this post and deliberately didn’t go deep on it. It deserves its own dedicated treatment — because Collections Management in D365 F&O is a genuinely powerful capability that most organizations barely scratch the surface of. Customer pools, collections agents, case management, interest automation, write-off workflows — we’ll walk through all of it and show you what a mature collections process in F&O actually looks like.

Until then — apply your payments, set your credit limits, and send your customers statements. The three simplest things you can do for AR health, and the three most consistently skipped.

— Bobbi

D365 Functional Architect · Recovering Controller