Revenue Recognition in D365 F&O: Understanding the Why Before the How
- Beau Schwieso
- Oct 27
- 4 min read
If you have ever tried to explain revenue recognition to someone new to ERP, you know it goes one of two ways:
Their eyes glaze over like you just asked them to name all 50 state capitals in alphabetical order.
They nod along confidently and then later ask why the income statement is “wrong.”
Revenue recognition can feel abstract because it has nothing to do with when you invoice a customer.
It has everything to do with when the business has actually delivered value. And if you get this part wrong, your financial statements stop telling the truth.
What Revenue Recognition Really Is (aka the basics)
Revenue recognition is the principle that revenue should be recorded when the company delivers value, not when the customer pays for it.
That’s it. That’s the whole thing. Blog over. Right? Keep going (please).
It does not matter:
When the invoice is issued
When the cash hits the bank
Or whether someone got excited and demanded finance “just book it already”
Example:
You sell a one-year software subscription.
The customer pays upfront.
You cannot recognize the full amount as revenue on day one.
You have not provided a year of service yet.
You earned only one month of value, so you only recognize one month of revenue.
The accounting world cares deeply about telling a faithful economic story. So revenue only counts when the work is done.
This is why billing and revenue recognition are not the same thing.
One is cash flow. The other is truth.
Where Revenue Recognition Happens in D365
In D365, revenue recognition can show up in a few different business scenarios. Think of them as different stories about how value is delivered.
There is no single revenue recognition model that fits all companies. The shape of the value drives the accounting.
The software just follows the story.
The Simple Scenario: Products
If you sell physical goods, life is straightforward.
When the goods leave your warehouse and are delivered to the customer, you have completed your part. So revenue is recognized at the point of delivery.
Billing may happen before or after that event. But the revenue clock starts when the product leaves your control.
Simple. Clean. No drama. No tears. Ok, maybe a little bit of tears.
Services and Projects: Value Happens Over Time
Ok, we've walked through arithmetic, let's get into some algebra. Now we get into real life.
Let’s say you are implementing D365 for a client. (Look at us. So meta.)
You bill them at the start of the project. Fine. That is billing.
But you have not delivered the project yet. You have barely figured out who needs access to what.
So how do you show revenue?
You recognize revenue as the work is completed, which means:
When consultants log time
When deliverables are met
When the project moves forward
You might recognize revenue based on:
Hours used vs hours estimated
Cost incurred vs total expected cost
Major milestones completed
This is revenue following progress.
If the work slows down, revenue slows down. If the project accelerates, revenue accelerates. Finance is telling the real story of how value is unfolding.
Deferred Revenue: When Money and Value Do Not Arrive Together
Deferred revenue happens when:
The customer pays upfront
But value is delivered later or over time
Example: A maintenance contract. A subscription. A multi-month service plan.
You are holding money for something you still owe the customer.
Until that work is delivered, the money sits on the balance sheet as a liability. Uncomfortable but true.
You have not earned it yet. So you cannot call it revenue yet.
As each month passes and the service continues, you release a portion of that deferred revenue into actual revenue.
Think of it like a very slow vending machine that dispenses only one Cheeto per day.
The Advanced Case: Percent of Completion
Here is where finance teams either look like geniuses or spend weeks explaining variance to executives.
Percent of completion applies to long-term projects where progress is gradual and measurable.
The idea:
If you are 40 percent done with a project
You can recognize 40 percent of the revenue
Even if the cash flow happened differently
But percent of completion lives or dies on one thing:
Your ability to estimate total cost or total effort accurately.
If your estimate is wrong:
Revenue is wrong
Gross margin is wrong
Profitability insights are wrong
And suddenly someone is asking why the CFO looks like they haven’t slept in three days
Percent of completion is powerful. But it demands discipline. It rewards mature organizations. It punishes chaos.
How to Choose Which Method Applies
If value is delivered when the customer receives the product - Recognize revenue on delivery.
If value is delivered as work is performed - Recognize revenue as time or progress occurs.
If value is delivered over time and prepaid - Recognize revenue on a schedule.
If value is delivered in phases and estimates are reliable - Use percent of completion.
If your estimates are not reliable - Do not use percent of completion. Your finance team will thank you. Your auditors will thank you. Your future self will thank you.
If revenue recognition worked the way my kids think it does, I would get credit for dinner the moment I thought about making it. But unfortunately, revenue, like dinner, only counts once it is actually served.
Just like me serving up these blogs, ba dum psh
DynamicsDad
Comments