Two companies, one template, and a month end that belongs to neither.
A consolidation does not break the ledger. It breaks the trail behind it — receipts posted on one side of the cutover, invoices arriving on the other, and opening balances nobody in the new entity can explain.
Two of these decisions cost nothing before go-live and a great deal afterwards. This page is about those.
One purchase order, two systems
Before go-live
Goods received against the order. Receipt posted in the system being retired.
After go-live
Supplier invoice arrives in the new entity. Nothing to match it against.
At month end
The line sits in goods received not invoiced, correct in both systems and wrong across the pair.
Finance & Operations and Business Central
Where we build, under your own security roles.
An identity with no permissions until granted
F&O version 10.0.47 onward.
Reading first, writing on approval
Nothing moves without a named approver.
Five things a consolidation does to the purchasing cycle
None of these is a defect in Dynamics 365, and none is anyone's mistake. They are what happens when two sets of books, two item catalogues and two role designs are asked to become one on a fixed date.
Receipts land on one side of the cutover and the invoice on the other
Stock is received in the system being retired, the invoice arrives after go-live in the system replacing it, and the three-way match has nothing to match against. The line is not wrong in either system. It is only wrong across the pair, which is the one view neither one shows.
Accrual balances arrive with no document trail anyone recognises
Goods received not invoiced carries over as an opening balance. The receipt behind each line was posted by a team that may no longer exist, against a purchase order in a numbering series nobody in the new entity has seen. The number is auditable; the reason behind it usually is not.
Two companies become intercompany overnight
Entities that invoiced each other as third parties last quarter are now internal, and the purchasing flow between them has to change on the day the legal structure does. The paperwork that was correct in both systems becomes an elimination problem in one.
Two item masters merge and the units of measure disagree
The same physical part arrives as an each in one catalogue and a case of twelve in the other. Quantities reconcile on paper and not on the shelf, and the error only shows up as a receipt that nobody will post because nobody believes it.
Security roles are copied from the template, not from the entity
One template rolled across several entities carries one role design. The segregation of duties that suited the first site rarely suits a site with four people in finance, and the gap is discovered by an auditor rather than by the project.
Every one of them is discoverable by reading the data. That is the part worth settling before the rollout fixes everyone's attention on go-live week.
Five decisions, and what each one costs if it waits
These sit beside the role design and the test script you are already writing. Taken then, they are a paragraph each. Taken during hypercare, they are a change request against a team with no slack.
| The decision | Taken before cutover | Taken after go-live |
|---|---|---|
| Who the agent is | An identity exists alongside the human roles being designed, with no permissions until someone grants them | A new identity is requested during hypercare, when nobody has time to review what it should be able to see |
| What the agent may change | Read everywhere, change nothing without a named approver, agreed while the approval matrix is still open | Retro-fitted to whatever the agent was already doing |
| Where the opening balances came from | Captured while the people who posted them are still on the project | Reconstructed from the ledger by whoever inherits it |
| Which exceptions a person must see | Written into the test script, so the exception path is exercised before real volume hits it | Discovered at the first month end on live data |
| What the agent costs to run | Estimated against the environment's own capacity, before the rollout fixes the budget | Found in an invoice |
From Dynamics 365 Finance & Operations version 10.0.47 an agent can hold its own identity, and it has no permissions at all until an administrator assigns roles to it. That is why the first row belongs next to your role design rather than after it.
Three agents, and an honest status on each
Each one reads a problem this page has already described. The status line matters more than the description, so it is on the card rather than in a footnote.
PO Receipt Chase agent
Finds purchase order lines that arrived but were never received in the ERP, lists them by buyer, and posts the receipt once the site confirms and a person approves.
During a cutover. The backlog a cutover creates is exactly this shape: physically in, not posted, and nobody sure which system should carry it.
Built, shown on request, test data in a demo environment.
Aged GRNI agent
Goes through goods received but not yet invoiced at month end and gives the reason for each line: a duplicate receipt, a partial delivery, a supplier who never billed.
During a cutover. Opening balances inherited from a retired system are the hardest lines to explain, and they are the ones an auditor asks about first.
Built, shown on request, test data in a demo environment.
Credit Hold agent
Shows why an order is on credit hold, with the evidence, and leaves the release to the credit manager.
During a cutover. Credit limits reset when entities merge, and orders stop for reasons the new credit team did not set.
Training build on Microsoft demo data, not yet run on a customer system.
Across the company four AI products are in production with 37 agents between them, and the team has delivered generative AI and optimization work inside a customer's Dynamics 365 Supply Chain environment. None of the three agents above is running at a customer, and nobody here will tell you otherwise on a call.
What people ask when the rollout is already running
We are mid-implementation. Is it too early to look at agents?
It is the cheapest moment to decide two things, and both get harder later: which identity an agent uses, and what it is allowed to change without a person saying yes. From Dynamics 365 Finance & Operations version 10.0.47 an agent can hold its own identity and has no permissions until an administrator assigns roles, so the decision sits naturally beside the role design you are already doing. Building the agent can wait. Designing where it fits should not.
Does this mean changing our implementation partner's plan?
No. Your partner owns the ERP and keeps running it, and we have never competed for that work. What we build reads through Microsoft's own supported integration points and proposes; a person approves anything that moves money or stock. Nothing is added to your tables.
We are folding an acquisition onto our template. Where does this start?
With the opening balances, because that is the evidence that decays fastest. The receipts and uninvoiced lines carried over from the system being retired can still be explained while the people who posted them are on the project. Six months later the same lines are a reconstruction exercise.
Our ERP is not Dynamics 365. Does any of this apply?
The pattern does and our builds do not. The receipt, accrual and intercompany problems above are the same on SAP, Oracle and Infor, and we are glad to compare notes on them. What we build runs inside Dynamics 365 Finance & Operations and Business Central, so a build conversation only makes sense if one of those is where you are heading.
What runs at a customer today?
Across the company, four AI products are in production with 37 agents between them, and the team has delivered generative AI and optimization work inside a customer's Dynamics 365 Supply Chain environment. Of the three month-end agents named on this page, two are built and shown on test data in a demo environment and one is a training build on Microsoft demo data. None of the three is running at a customer, and we will not tell you otherwise on a call.
Can you work during hypercare without adding risk to the cutover?
Reading is the part that carries no risk, and it is most of the value during hypercare: the exception list, the reason behind each line, and the evidence a person needs to act. Anything that writes waits for a named approver and is logged. If a cutover is in flight, reading first and writing later is usually the right order anyway.