Home / Resources / Blog / Details

In this article:

A Spicy Guide to Handling Disputes Like a Chilli Pepper Pro The Scoville Scale of Client Disagreements From Jalapeo to Carolina Reaper The Cooling Remedies How to Tame the Heat of Client Disagreements

Ready to transform your business with subscriptions?

Discover how we can help you achieve sustainable revenue growth and enhanced customer loyalty. Contact us today to learn more!

Let's Chat

Schedule a free, no-obligation discover call today!

Are Client Disagreements Burning You Up?

10.07.2023

Thinking

A Spicy Guide to Handling Disputes Like a Chilli Pepper Pro

Client disagreements are a nightmare.

Even if you think you can handle them, they can completely catch you off-guard. They can get worse and worse. They can completely disable your abilities to think about anything else.

Client disagreements are just like eating chilli peppers that just keep getting hotter and hotter.

When was the last time you ate a chilli that was waaaay too hot for you? You sweat bullets. You reach for the nearest beverage (hope it’s not wine!). You might even hiccup like crazy.

And all the time, you wonder – why, why, why, do you put yourself through this?

Right now your tongue might be metaphorically on fire as you try to navigate the heated world of client dissatisfaction. Because client disagreements are PAINFUL.

As business leaders, we know that client disagreements are inevitable.

But much like the world’s spiciest chilli peppers, these disputes can range from mildly irritating (think jalapeños) to downright catastrophic (hello, Carolina Reaper).

The key to keeping your finance and revenue numbers in check—and your taste buds intact—is understanding the different types of disagreements and their potential impact on your business.

So we’re gonna take you through a little guide – the Scoville scale of client disputes – and learn how to handle them like a chilli pepper connoisseur.

With Bluefort’s end-to-end digital operating platform, you can streamline and hyper automate your processed, to put an end to disagreements, and actually impress your clients.

Grab your glass of cold milk and let’s go!

The Scoville Scale of Client Disagreements: From Jalapeño to Carolina Reaper

Jalapeño-Level Disputes (2,500 – 8,000 SHUs): Minor Miscommunications

These little disagreements usually come from simple miscommunications or misunderstandings. Though they cause a little discomfort, they’re usually resolved fast, with open communication and transparency.

Damage level: Tingling tongue, a few burps.Cayenne-Level Conflicts (30,000 – 50,000 SHUs): Unmet Expectations

Okay, it’s getting a little hot in here. Clients feel their expectations haven’t been met. This can involve project scope, deliverables, or timelines. This level means you have to be proactive – don’t wait till things blow up. Stop the problem where it is.

Damage level: Get your hands on the strongest antacids you’ve got and start popping those bad boys like chocolate buttons at Easter.Habanero-Level Hassles (100,000 – 350,000 SHUs): Contractual Disputes

Whew, NOW we’re getting spicy. Contractual disputes usually have something to do payment terms, service level agreements, or other legally-binding things. This is where customer disagreements can have a big impact that requires mediation or legal intervention to resolve.

Damage level: Your friends film you gasping with eyes bugging out, knocking over the stuff on the table in desperation…and the film goes viral. Ghost Pepper-Level Grievances (855,000 – 1,041,427 SHUs): Ethical Concerns

Man do things escalate fast when there are ethical concerns. We’re not saying you’re unethical! We’re saying there’s a perception of that. It could be a lack of corporate social responsibility. It could be questionable business practices. Maybe you have partner who has gone rogue. These client disagreements MUST be sorted rapidly before your company’s reputation is ruined.

Damage Level: You’ve got third-degree burns going in and out and you are not taking visitors.Carolina Reaper-Level Rifts (1,569,300 – 2,200,000 SHUs): Major Breaches of Trust

The Carolina Reaper of client disagreements involves major breaches of trust, such as fraud, theft, or other serious misconduct. These disputes can lead to financial ruin, the dissolution of the business relationship, fines, and even prison.

Damage Level: You are now dead. And no one goes to your funeral.

Sounds familiar, right? The thing is, even if you’re on top of all your company’s processes, you’re going to have client disagreements.

In fact that’s probably why you’re reading this article now. So let’s get to what can be done about it.

The Cooling Remedies: How to Tame the Heat of Client Disagreements

What are some cooling remedies for managing these fiery situations?

1. Transparency

Be upfront and clear with your clients about project scope, deliverables, and timelines from the outset. Get everything in writing.

2. Active Listening

Ensure you fully understand your clients’ expectations and concerns. Know their definitions for the words you use (ie how do you both define “timely”?) Actively listen to their feedback, and work together to find solutions.

3. Regular Check-Ins

Schedule regular check-ins with your clients to discuss progress, address any issues that arise, and keep that strong working relationship going.

4. Contract Clarity

Make sure your contracts are clear, concise, and easily understood by both parties.

5. Ethical Business Practices

This goes without saying, but be ethical! Integrity is everything. On the flip side, deal with clients who have good reputations too.

6. Open Dialogue

Both sides must be able to say difficult things. But it increases trust, and helps solve disagreements before they get worse.

7. Professional Mediation

When direct communication isn’t enough, bring in a professional (or professionals) that both sides trust.

8. Automation

Implement automation tools that will take care of the end-to-end process. Automation streamlines communication, project management, and reporting. It cuts down misunderstandings, creates timely updates, and provides a high level of service for your clients.

Client disagreements can range from mildly irritating to downright fiery, just like those chilli peppers that some of us adventurous (misguided) people like to try.

By understanding the different types of disputes and their potential impact on your business, you can navigate these situations with grace and skill—and keep your taste buds (and finances) intact.Want to see how hyper-efficient processes and automation can help cut down client disagreements?

Share on Socials:

Let’s chat further.

"*" indicates required fields

The Two Silent Killers of Dynamics 365 As-a-Service Transformations

Ask a manufacturer why their As-a-Service transition stalled, and you rarely get “we didn’t want it enough.” Leadership signed off. The strategy made sense on paper. The market case was real. And yet, across the more than 500 industrial As-a-Service transitions P2S Management Consulting has studied, most transformations stall anyway. That’s the uncomfortable part of this work: the failure point is almost never visible on the plan. It’s not a missing line item or a skipped approval. It’s something that looks fine in the deck and quietly sinks the model anyway. And here’s the detail most executives miss when they’re bracing for it: that failure point isn’t fixed. It moves, depending on what stage of the transition you’re in. Watch for the wrong one, and you’ll have your eyes on last quarter’s risk while this quarter’s is compounding. Killer #1: Leadership buy-in, early on The first silent killer shows up at the very beginning, while the model is still being designed, and it has almost nothing to do with strategy. It’s about incentives. Here’s how it plays out. Everyone in the room agrees the As-a-Service model is the right move. The pitch deck is compelling. The pilot gets approved. But the sales team is still being paid, in practice, the same way it always was: commission on machines sold. And if your best rep still earns more for pushing a CAPEX deal than for closing an outcome-based contract, the strategic intent at the top of the business never survives contact with the sales floor. Nobody has to sabotage the model. It’s enough that nobody’s incentives changed. This is why “leadership buy-in” has to mean more than a mandate from the top. It has to show up in the compensation plan, because that’s the only place a sales organization actually listens. Killer #2: Billing and the platform underneath, once you scale The second killer doesn’t show up at the start. It shows up later, once the pilot has proven itself and the business starts pushing volume through the model, and it’s a completely different kind of failure. This one is operational, not cultural. A handful of outcome-based contracts is manageable on almost anything, including a spreadsheet and a diligent finance person reconciling usage against invoices by hand. It works, right up until it doesn’t. Somewhere around the tenth contract, for reasons we’ve unpacked in more detail elsewhere, the manual effort behind the billing stops scaling with contract count and starts scaling faster than it. What looked like a proven, repeatable process on paper starts eating headcount instead, and a strategy that was genuinely sound starts looking, from the outside, like it isn’t working. For a Dynamics 365 manufacturer specifically, this killer has a name and a location. Standard D365 Finance and Supply Chain Management (and Business Central) handles core invoicing well, but it doesn’t natively track what a customer is entitled to receive against what they’ve consumed, doesn’t automatically catch overage, and doesn’t give a portfolio-level, governed view of what each contract actually promises. Those gaps are exactly where the manual effort piles up, and exactly where the second killer lives. The killer moves, so your attention has to move with it The practical implication is that “watch for the silent killer” isn’t a single, fixed piece of advice. It’s a sequencing problem. Early in a transformation, the thing worth interrogating hardest is whether sales incentives have genuinely changed, not just whether leadership has said the right things in a town hall. Later, once the model is scaling, the question shifts entirely to whether the platform underneath, inside Dynamics 365, specifically, can run the commercial model at real volume without absorbing headcount as it grows. Transformations that hold up tend to share one habit: they don’t treat these as one problem solved once. They check both, at the point in the journey where each one actually bites, rather than assuming that clearing the first means the second won’t arrive. We unpacked both silent killers in more detail, including a real, anonymized case of a mid-market manufacturer that hit exactly this pattern, in a recent joint session with P2S Management Consulting. Watch the on-demand session: Why Manufacturers Struggle to Grow Service Revenue in Dynamics 365, and How to Fix It Read the full research: From Products to Outcomes: The Dynamics Manufacturer’s Guide to Winning with Service-Based Models, Download the eBook

20.08.2026 Manufacturing

Why Now? The Four Forces Ending Product-Only Growth in Manufacturing

If you build or sell industrial equipment, you've heard the pitch before: sell the outcome, not the machine. It's not a new idea; manufacturers have been hearing some version of it for over a decade. And yet, walk the floor of almost any industrial trade show today, and the majority of the market is still selling machines. So the interesting question isn't whether outcome-based, service-led revenue models work in theory. It's why so many capable manufacturers who try them stall , and why, despite that, 2026 is a genuinely different moment to make the shift than 2016 was. The answer comes down to four structural forces. None of them is speculative. All four are visible in the market right now. 1. The margin has left the machine Start with where the money actually is. Look across the manufacturing sector and a consistent pattern shows up: aftermarket and service revenue tends to run at roughly 25% margin, while new equipment sales sit closer to 10%. That's not a rounding difference; it means the bulk of the profit in an asset's life increasingly sits in the service relationship that follows the sale, not in the sale itself. That has a sharper implication than “services are nice to have.” It means a manufacturer who competes purely on shipping units is, in effect, competing to win the low-margin third of the value an asset will generate over its life, and handing the other two-thirds to whoever services it, finances it, or operates it afterward. Sometimes that's a competitor. Increasingly, it's a third party with no stake in the equipment at all. 2. Buyers are procuring outcomes, not equipment The second force is on the demand side. Procurement teams are changing what they ask for. Recent research puts outcome-based purchasing at roughly a quarter of manufacturing procurement decisions today, with buyers expecting that figure to climb toward half within the next decade. This isn't buyers being difficult. It's buyers applying the same logic to industrial equipment that they've long applied to mission-critical infrastructure: they want guaranteed performance, predictable cost, and one accountable party, not a piece of capital equipment and a warranty card. In sectors that made this shift early - construction equipment, aircraft engines, HVAC , service revenue already accounts for somewhere between 50% and 65% of total revenue. That's not an emerging trend in those categories anymore. It's simply how the market works now. 3. The measurement barrier is gone For a long time, the honest objection to outcome-based models was practical, not strategic: you can't bill for what you can't measure. Guaranteeing uptime, output, or efficiency requires knowing, continuously and verifiably, whether you're delivering it. That constraint has largely dissolved. With something in the order of 21 billion connected devices now in operation, the infrastructure for continuous performance monitoring is no longer a bespoke engineering project; it's increasingly standard on the equipment manufacturers already ship. The question has quietly shifted from “can we measure this?” to “have we built the commercial and contractual structure to act on what we're already measuring?” For most manufacturers, the honest answer is: not yet. 4. The early-mover gap compounds The fourth force is the one that punishes hesitation specifically. Outcome-based contracts don't just carry higher deal values; they run for years and renew, rather than resetting to zero at the start of every sales cycle. Every multi-year outcome contract a competitor signs takes that customer off the market for the length of the contract, often the better part of a decade. That's a fundamentally different competitive dynamic than product sales, where this quarter's loss is next quarter's opportunity. In outcome-based markets, the provider who signs first doesn't just win a deal; they remove a competitor's future opportunity to bid at all. The gap between early movers and everyone else doesn't stay flat. It compounds, one contract at a time. So why now, specifically? Put the four together, and the picture is less “outcome-based models are a good idea” and more “the market has moved, whether or not you've moved with it.” The margin has already relocated to service. Buyers are already asking for outcomes. The technology to measure and bill for them is already in place. And the manufacturers who acted on this earliest are already several contracts into locking up their addressable market. None of that means every manufacturer should attempt this transition, or that it's simple once you decide to. In our experience, and in the more than 500 industrial As-a-Service transitions behind the research this piece draws on, the harder and more common problem isn't deciding whether outcome-based revenue makes sense. It's that most transformations stall on operations, not strategy: pricing that finance can't account for, contracts that legal can't govern, and billing that the underlying systems can't actually run. That's the part worth getting right before the first contract is signed, not after. It's also exactly what we unpacked, in more practical detail, in a recent joint session with P2S Management Consulting, including the two “silent killers” that quietly sink most transformations, and where a standard Dynamics 365 environment can and can't carry an outcome-based model without help. Watch the on-demand session: Why Manufacturers Struggle to Grow Service Revenue in Dynamics 365 , and How to Fix It Read the full research: From Products to Outcomes: The Dynamics Manufacturer's Guide to Winning with Service-Based Models, Download the eBook

18.08.2026 AI

The BC Implementation Opportunity Nobody Is Talking About Yet

Every BC implementation partner knows the pattern: margin absorbed, timelines extended, client expectations managed downward. The opportunity to change that is arriving, and most of the ecosystem has not yet looked up from the current process long enough to see it. There is a process at the centre of every Business Central implementation that has remained essentially unchanged since the platform was first deployed at scale. A client describes a business requirement. A functional consultant interprets it. A developer translates the interpretation into AL code. Someone tests the result manually. Feedback comes back. The cycle repeats. The number of tools available to support this process has grown considerably. The process itself has not. The requirement-to-production cycle in BC customisation is still, at its core, a handmade process. Each extension is built from scratch or adapted from a prior project. Each test is run by a person following a test script. Each deployment is managed by a developer who understands the specific configuration of this client's BC environment. This is not a criticism of the people doing the work. BC implementation teams are, in many cases, operating at the limit of what the current process allows. The problem is the process, and the process has structural characteristics that make it resistant to improvement within its existing design. Why the cycle is so hard to compress The requirement-to-production cycle in BC is long for reasons that are interconnected and mutually reinforcing. The first is the translation problem. Business requirements are expressed in operational language. The person describing the requirement understands what the business needs, but not necessarily how BC's data model, permission architecture, or extension framework will accommodate it. The developer understands the implementation constraints, but not necessarily the business context that makes one approach preferable to another. The functional consultant sits between them, translating in both directions. This translation layer adds time, introduces interpretation errors, and creates a feedback loop that is difficult to short-circuit. The second is the testing problem. Manual testing of BC customisations is time-consuming, inconsistent, and incomplete. Test scripts capture the scenarios the tester anticipates. They do not capture the scenarios the tester did not think to test, which are precisely the scenarios most likely to surface as production issues after go-live. Automated testing in BC environments exists but is not yet standard practice across the partner ecosystem, and implementing it adds a layer of upfront investment that many projects cannot absorb. The third is the knowledge problem. Every BC implementation accumulates environment-specific knowledge, configuration decisions made early in the project, integrations added at different points, customisations that interact with each other in ways that are not always fully documented. This knowledge lives primarily in the heads of the people who built the system. When those people are not available, or when a new requirement touches a part of the environment they did not build, the investigation work required before a new extension can be safely developed adds time that the project timeline did not anticipate. What this costs The cost of the handmade build process is distributed across three places. Partners absorb it in margin. Projects that were scoped on the assumption of a linear, well-understood build process encounter translation delays, testing rework, and knowledge investigation work that was not in the estimate. The additional effort comes out of the project margin rather than the client's budget, because raising a change request for work that should have been part of the original scope is a conversation nobody wants to have. Clients absorb it in timeline. The requirement that was described in week three of the project is tested in week eleven. By week eleven, the business context has shifted. The person who described the requirement has moved to a different role. The urgency that justified the customisation has either intensified or resolved without the system's involvement. The relationship absorbs it in trust. A client who expected a three-month implementation and experienced a five-month one, with a final result that only partially matches what was described, does not approach the next project with the same confidence. The gap between what was promised and what was delivered is the gap where partner-client relationships erode. Why this is a structural problem, not an execution problem The instinctive response to the build problem is to improve execution within the existing process. Better project management. Better requirements documentation. More experienced developers. More thorough testing. These improvements help at the margin. They do not change the structural characteristics of the process. The translation layer is still there. The manual testing is still there. The environment-specific knowledge is still concentrated in individuals rather than systematically captured. The build problem in Business Central is not a problem that can be solved by doing the same thing better. It requires a different approach to how requirements become extensions, how extensions are tested, and how environment knowledge is captured and reused. That different approach is beginning to arrive in the Dynamics ecosystem. Microsoft's announcement of Project MIA at DynamicsMinds in May 2026, aimed initially at F&SCM partners, signals that the ecosystem's direction of travel is toward AI-assisted implementation. What that means for BC, and on what timeline, has not yet been confirmed. What is clear is that the build problem is recognised at the highest level of the ecosystem, and that the current process is not the destination. The partners and clients who understand the structural nature of the problem now will be better positioned to evaluate and adopt what comes next. The ones who attribute it to execution will keep trying to fix the wrong thing.

06.08.2026 AI

Clean Data Isn’t a Project. It Is a Precondition.

Every conversation about AI in Business Central eventually arrives at the same place. The data. Here is why that conversation needs to happen first, not last. When organisations begin evaluating AI for their Business Central environment, they typically start with the use case. What do we want the AI to do? Which workflows do we want to automate? Where is the biggest opportunity for the system to act on our behalf and return time to the team? These are the right questions to be asking. They are also, in most cases, the second questions. The first question is one most organisations have not yet answered with enough specificity to move forward confidently. What is the quality of the data the AI will be reading? We have been thinking about this for long enough to have watched the pattern repeat across multiple client conversations. The enthusiasm for what AI can do is genuine. The readiness of the data environment it will operate in is consistently overestimated. And the gap between those two things is where AI deployments underperform. Not because the AI is wrong. Because the AI is right about the wrong data. What clean data actually means Clean data is not the absence of errors. Every live business system accumulates some degree of data imperfection over time. Duplicate records that were never merged. Pricing structures that were updated in one entity but not another. Item descriptions that reflect a product catalogue from three years ago. Clean data, in the context of AI in Business Central, means something more specific. It means that the data the AI will read to make a decision is accurate, current, and consistently structured across the entities and environments the AI will operate in. For a pricing AI, clean data means that the customer's pricing agreement is recorded accurately in BC, that it reflects the current commercial terms, and that it is consistent with what the sales team has on record in the CRM. A pricing AI reading a price list that is three months out of date is not making a pricing decision. It is making a historical one. For a subscription management AI, clean data means that the contract terms recorded in BC reflect what the customer actually agreed to, that the renewal dates are accurate, and that the billing entity is correctly assigned. A subscription AI processing a renewal against incorrect contract terms does not produce a wrong output. It produces a precisely correct output of the wrong input. For an access governance AI, clean data means that the user records in BC accurately reflect the current team, that former employees have been deactivated, and that role assignments reflect current responsibilities rather than historical ones. An access governance AI analysing an environment where twenty percent of the user records are outdated is not producing an access review. It is producing an access review with a twenty percent blind spot. Why this is a precondition and not a project The reason we describe clean data as a precondition rather than a project is that the distinction changes how organisations approach it. A project has a timeline, a budget, a delivery date, and a defined scope. When data quality is treated as a project, it is planned, resourced, executed, and then considered done. The AI deployment follows. Two years later, the data quality has degraded back to its pre-project state because the underlying processes that generate the data have not changed, and nobody has maintained the work that was done. A precondition is different. A precondition is a standard the environment must meet before the AI can be trusted to operate in it. And maintaining that standard is an ongoing operational responsibility, not a one-time project. The practical implication is that before an AI deployment begins, the organisation needs to establish not just that the data is clean enough to start, but that the processes which generate the data will keep it clean enough to sustain. Who is responsible for data quality in the domains the AI will operate in? What is the process for identifying and correcting data errors when they occur? How frequently is the data reviewed? Who is accountable when the AI produces an output that traces back to a data quality failure? These are operational governance questions. Answering them is the precondition work. It is less exciting than configuring the AI. It is more important. What this means in practice for BC environments For most mid-market BC environments, the precondition work involves three things. The first is an audit of the data the AI will act on, focused on the specific domains relevant to the intended use cases. Not a full data quality assessment of the entire BC environment, but a targeted review of customer records, pricing structures, contract terms, user assignments, or whatever data the AI will be reading. The second is a remediation pass. Duplicates resolved, outdated records corrected, inconsistencies between entities aligned. This is the one-time project component. It needs to happen before go-live. The third is a governance design for ongoing data quality. Who owns the data in each domain? What is the process when a discrepancy is identified? What monitoring is in place to surface data quality issues before they reach the AI? This is the operational component. It needs to be in place before the AI goes live, and it needs to be maintained after. The organisations that get this right treat data quality as part of the AI governance framework, not as a separate workstream that happened before the AI project started. The AI and the data are one system. Governing one without governing the other is not a complete governance programme. The sequence that works At Bluefort, the sequence we have found that works is: clean data first, connected data second, governed AI third. Clean data means the records the AI reads are accurate and current. Connected data means the systems holding relevant data are synchronised in real time across the full Dynamics ecosystem. Governed AI means the AI operates within a policy framework the business defines, with a complete audit trail and the approval mechanisms to make that governance real. Each step in that sequence depends on the one before it. Governed AI on unclean data is governance of the wrong decisions. Connected data feeding unclean records is a wider distribution of the same inaccuracies. Clean data without connection is an accurate but incomplete picture. The sequence matters as much as each individual step.

04.08.2026 AI

Every Gap in Your Integration Is a Gap in Your AI

The quality of AI in Business Central is not determined by the sophistication of the AI. It is determined by the completeness of the data the AI reads. And the completeness of the data depends on the integration. There is a version of AI deployment that looks successful on a demonstration and underperforms in production. The AI is correctly configured. The governance framework is in place. The use cases are well-defined. And yet the outputs are inconsistent, the exceptions are frequent, and the finance team does not trust what the system is telling them. In most cases, the explanation is not the AI. It is the integration. Business Central does not operate in isolation. For the vast majority of mid-market organisations, it sits at the centre of a technology environment that includes a CRM, a customer success platform, a payment processor, and often a separate reporting or analytics layer. The data that matters for AI decisions is distributed across those systems. The AI reads what it can reach. What it cannot reach, it cannot account for. Every gap in that integration is a gap in what the AI knows. And a gap in what the AI knows is a gap in the quality of every decision the AI makes. What integration completeness actually means Integration completeness does not mean that every system in the organisation is connected to Business Central. It means that the systems containing data relevant to the AI's decision domain are connected, synchronised in real time, and producing data that is structured consistently enough for the AI to read with confidence. For a pricing AI, integration completeness means that the customer's current contract tier, their pricing agreement, their regional market signals, and their account status are all available inside BC at the moment the pricing decision is made. If any of those data points lives in a system that is not connected, or that synchronises on a nightly batch rather than in real time, the pricing decision is made on a partial picture. For a subscription management AI, integration completeness means that the customer's service history, their renewal terms, their payment behaviour, and their current support status are all visible inside the BC environment where the subscription is being processed. A subscription renewal processed without visibility of an unresolved support case, or without the updated contract terms agreed by the sales team in the CRM, is a renewal processed on incomplete information. The pattern is the same across every AI domain: the AI's decision quality is bounded by its data completeness. And its data completeness is bounded by the integration. The integration debt most BC environments carry Most mid-market BC environments carry integration debt. Not because integration was neglected, but because integration is typically built for the requirements of the moment rather than the requirements of the future. When a CRM integration is built, it is built to synchronise the data that matters for the business processes running at the time. As the business grows and processes evolve, the integration is extended incrementally. Some extensions are well-documented. Others are patched in response to a specific operational need and never fully reviewed. The result, across three to five years of normal business operation, is an integration that works well enough for the workflows it was designed to support and has unmapped gaps in the areas it was not designed to cover. Those unmapped gaps are invisible in normal operation. They become visible the moment an AI system tries to make a decision that depends on data sitting on the other side of one of them. The Dataverse connection as foundation For Business Central environments operating within the broader Microsoft Dynamics 365 ecosystem, the Microsoft Dataverse connection is the integration foundation that determines how much of the surrounding data landscape is available to AI running inside BC. A complete, well-configured Dataverse integration means that data from Dynamics 365 Sales, Customer Insights, Customer Service, and the broader Power Platform is continuously synchronised and available inside the BC data model. The AI running inside BC is not making decisions from a BC-only view of the customer. It is making decisions from a unified view of the customer across the full Dynamics ecosystem. An incomplete Dataverse integration means the opposite. The CRM data is out of date, or partially synchronised, or requires a manual refresh to reflect the current state of the customer relationship. The AI sees a snapshot rather than a live picture. And a snapshot, in a fast-moving commercial environment, is a basis for decisions that are already behind reality. What to do about integration gaps before deploying AI Before deploying AI in any domain inside Business Central, map the data the AI will need to read for each decision it will be making. For each data point, identify which system holds it and whether it is currently available inside BC in real time. Where gaps exist, assess whether closing them is a prerequisite for the AI use case or whether the use case can be scoped to operate within the data that is currently available. This mapping exercise is not lengthy. For most organisations, the relevant data domains for an initial AI deployment are narrow enough that the integration audit takes days rather than weeks. The output is a clear picture of what is ready, what needs work, and what can be deferred. The alternative is to deploy AI on the assumption that the integration is complete, discover the gaps in production, and spend the first months of the AI deployment explaining to the finance team why the outputs are inconsistent. That is a more expensive path, and a less forgiving one. The quality of AI in Business Central starts with the integration. Get that right first.

31.07.2026 AI

What ‘Governed AI’ Actually Means in an ERP Context

'Governed AI' is becoming a common phrase in the enterprise technology conversation. It is worth being precise about what it actually means - and what it requires - before the term loses its meaning entirely. Governance is one of those words that accumulates definitions. Ask ten technology vendors what governed AI means and you will receive ten different answers — most of them reassuring, few of them specific. Governed AI means the AI operates within guardrails. Governed AI means there is a human in the loop. Governed AI means the AI is responsible. These answers are not wrong. They are insufficient. In an ERP context specifically, governed AI has a precise meaning — and that precision is what separates a genuine governance capability from a marketing claim. Here is what governed AI actually requires in a Business Central environment. A policy framework the business defines — not the vendor The first requirement of governed AI in an ERP is that the governance rules are set by the business, not inherited from the software. This is a more important distinction than it appears. An AI system that has its own built-in governance defaults — thresholds, confidence levels, approval triggers — may be well-designed. But it is still an AI system making assumptions about how the business operates and what level of autonomy is acceptable. Those assumptions may not match the business's actual risk tolerance, its audit requirements, or its regulatory environment. Genuinely governed AI in Business Central allows the business to define the policy framework within which the AI operates. Which transaction types may be processed autonomously within defined parameters? At what value threshold does an action require human approval before execution? Which accounts, which items, which customer segments are excluded from automated processing entirely? Which team member or role is the designated approver for which category of exception? These are business decisions. They belong to the finance director, the operations lead, and the compliance team — not to the software configuration defaults. A confidence score on every decision The second requirement is that every AI decision carries a confidence score — a quantified statement of how certain the system was when it made the decision, and whether that certainty was above or below the threshold required for autonomous action. This matters for two reasons. First, it determines the routing. A decision made at high confidence within policy guardrails proceeds automatically. A decision made below the confidence threshold routes to a human approver with the AI's recommendation and the reasoning behind it. The confidence score is the mechanism that distinguishes autonomous action from supervised recommendation. Second, it creates a reviewable record. When a finance controller or an auditor reviews the AI's activity, they are not reviewing a list of outcomes. They are reviewing a list of decisions, each with its confidence level, its triggering rule, and its routing outcome. That is a fundamentally different audit experience from reviewing a transaction log and trying to reconstruct what the AI was doing. A reason code on every action The third requirement is that every AI action carries a reason code — a structured explanation of why the action was taken, which rule applied, and what data the AI was acting on when it made the decision. Reason codes are what make AI decisions contestable. If a pricing action looks wrong, the reason code shows which pricing rule applied and at what confidence level. If a subscription term was processed differently from what the customer expected, the reason code shows what the AI read and how it interpreted the contract. If an access assignment was made that the auditor is questioning, the reason code shows the trigger condition and the policy the assignment was made under. Without reason codes, AI decisions can be audited for outcome but not for process. With reason codes, every decision has an explanation — and every explanation can be examined, challenged, and if necessary corrected. A rollback capability The fourth requirement is that AI actions can be reversed. Not every action — some ERP transactions, once posted, have downstream consequences that make simple reversal impractical. But the governance framework should include a defined rollback process for AI-initiated actions within a specified window, with a complete record of what was reversed, by whom, and why. Rollback is the safety net that makes the governance framework credible. An organisation that can say with confidence 'if the AI makes a wrong decision, here is exactly how we reverse it, who authorises the reversal, and how quickly it can be done' is an organisation that has done the governance work properly. An organisation that cannot answer that question has a governance framework that exists on paper but has not been tested in practice. An approval workflow that is part of the process, not an override of it The fifth requirement is that human approval — where the governance framework requires it — is built into the process, not grafted on top of it. There is a version of 'human in the loop' that is performative: a confirmation screen that appears before high-value actions, which approvers routinely click through without reading because the AI has never been wrong before. This is not governance. It is the appearance of governance. Genuine approval workflow means the approver receives the AI's recommendation alongside the confidence score, the reason code, and the relevant context — the data the AI was acting on, the rule it was applying, and the exception that triggered the review. The approver is in a position to make a genuine decision, not just ratify a system output. The test that separates governance from the appearance of governance Here is the test worth applying to any AI system operating inside an ERP. Ask it five questions. Can you show me the confidence score on this decision? Can you show me the reason code? Can you show me who — or what threshold — determined that this decision was eligible for autonomous action? Can you show me what the rollback process is if this decision turns out to be wrong? And can you show me the policy document that the business approved, within which this AI has been authorised to operate? If all five questions have clear, specific, documented answers — the AI is governed. If any of them cannot be answered, the governance is incomplete. The phrase 'governed AI' is worth preserving. The way to preserve it is to be precise about what it means.