Products
Business Central | Subscription Management Microsoft Dynamics 365 Business Central for Recurring Revenue SMBs
Subscription Finance that can build into a Cloud ERP as your business scales.
LISA Enterprise Microsoft Dynamics 365 FSCM with Supercharged Subscription Management
Powerful Cloud ERP for scaling recurring revenue corporations.
TAPP Payment fulfilment for Microsoft Dynamics 365 Apps
Complete, powerful payment automation for all recurring revenue business
types and sizes. With Stripe and Go Cardless.
Industry SaaS / Software Retail & eCommerce Memberships Microsoft Partners
Home
Solutions
Smb Product Suite
LISA Business
LISA Contract Entry Agent
TAPP for D365 BC & Sales
BC-Dataverse Integrator
Enterprise Product Suite
LISA Enterprise
TAPP Finance & Sales
Industries
SaaS / Software
Retail & eCommerce
Memberships
Microsoft Partners
e-Learning
Energy Retail
Resources
Blog
Learning Portal
Guides
Pricing
Partners
Enterprise Partners
SMB Partners
Company
About
Career
Book a Demo
© 2026, Bluefort.
All Rights Reserved.
SMB Product Suite Enterprise Product Suite Industries
SMB Product Suite
Subscription Management LISA Business Business Central Subscription & Recurring Revenue Management, supercharged.
Subscription Management LISA Contract Entry Agent Agentic AI for Subscription & Recurring Revenue Management in LISA Business.
Any Vertical Application TAPP for D365 BC & Sales One click end-to-end cash collection & management in D365 BC & Sales.
Any Vertical Application BC-Dataverse Integrator Seamless & complete data synch between D365 BC and the Dynamics CE stack.
Enterprise Product Suite
Subscription Management LISA Enterprise The most powerful Subscription & Recurring Revenue engine for D365 FSCM.
Any Vertical Application TAPP Finance & Sales One click end-to-end cash collection & management in D365 Finance & Sales.
Industries
SaaS / Software
Retail & eCommerce
Memberships
Microsoft Partners
e-Learning
Energy Retail
Book a Demo
  • Solutions
    • Products
      • Business Central
      • LISA Enterprise
      • TAPP
    • Industry
      • SaaS
      • Retail and e-Commerce
      • Memberships
      • Microsoft Partners
  • Resources
    • Blog
    • Learning Portal
    • Guides
  • Pricing
  • Partners
    • Enterprise Partners
    • SMB Partners
  • Company
    • About
    • Careers
  • Menu Menu
Book a Demo
Home / Resources / Blog / Details
In this article:
Managing recurring transactional events in Healthcare business processes Diagnosetoprescribe Prescriptiontopay Deliverandreceive
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!

Healthcare Subscription Models

20.12.2020
Thinking

Healthcare has become a complex industry to manage in an ERP; medical money-trails are managed differently between countries and the continuous changes in patient care as new innovations and products are developed.

An emerging business-model is to provide healthcare subscription models for patients or company employees. Rather than requesting refunds from healthcare insurance companies or healthcare providers, a subscription model can cover the required needs a patient might have. The rise of e-commerce and home-delivery has accelerated as a spinoff from Covid-19, fuelling an increased need for an easy-to-use and simplified healthcare model. Patients are often in need of various medicals equipment or medicines. Many needs are recurring for example asthma patients requiring inhalers or other daily chronic medicines. Chronic healthcare often require recurring prescriptions, but acute conditions or “once-off” transactions are also plentiful. Many countries provide healthcare insurances based on a recurring pattern. Healthcare providers specialising in services or products are in need of business models that support recurring events and patterns of delivery and payments.

The benefits of a subscription-based model for healthcare providers include:

  1. Reduce caseload of healthcare workers;
  2. Improve patient ease-of-use for self-medicating;
  3. Reduce administrative processes and consequent costs;
  4. Improve consistency in healthcare services and deliveries;
  5. Improve quality and safety of care services.

In this article we’ll explore how a subscription model can drive efficient business processes in the healthcare industry.

Managing recurring transactional events in Healthcare business processes

Healthcare transactional events involve capturing the patient information, related healthcare insurance provider, healthcare professionals and the provisioning of services and products. Let’s zoom into the recurring events:

  1. The patient requires periodic delivery of products based on a prescription, healthcare plan or therapy, covered by a subscription plan;
  2. Healthcare providers offer subscription plans to their patients, such as insurance plans, concierge services or treatment plans.

The above events can be driven by both patient and healthcare provider in a digital fashion, using portals and eCommerce capabilities. At the same time, it is important to capture the eco-system that surrounds the healthcare provider and the patient, since it is not the same as a customer-supplier relationship. The eco-system often represents multiple parties that support the patient. An example is show below.

Apart from the people in the view above, there is a B2B2C relationship where healthcare providers support medical companies who provide care service or products to patients.

The eco-system plays an important role in order for the patient to consume the prescriptions, services or goods. A simple process flow illustrates this example:

This process is often manual and paper based, making it time consuming. Automating this process will clearly drive many benefits. How can this be achieved practically?

Automating the process of providing a recurring prescription need to pass though several events in the eco-system. There are three main components to the transactions:

  1. Capturing the prescription and related subscription: diagnose-to-prescribe;
  2. Processing the (periodic) payment events: prescription-to-pay;
  3. Processing the continues provisioning of services and goods: deliver-and-receive.

Diagnose-to-prescribe

In this process the healthcare professional receives a patient during a visit. A diagnosis is made and treatment is established. The practitioner approves the prescription for the patient. The prescription carries the period of treatment and the provided services or medicine, as well as the recurrence cycle. In data terms, the practitioner issues a prescription order.

Once the prescription details are captured for the patient, the core data elements are now in place, which are:

  • The period or term of the prescription (for example 6 months or a year)
  • The products or medicine required and their delivery cycles/refills
  • The approval of the appropriate right authority

At this point the data is captured during the patient journey, supported by the eco-system explained earlier. In Microsoft Dynamics 365 this process is supported by the Healthcare Accelerator or using best-in-class partner solutions, such as Mazik’s healthcare solution.

When the prescription is written, the transaction really resembles an order on an eCommerce website. The reordering, with approval should be a movement of data between the eco-system and then to the provider to be able to fulfil the prescribed treatment.

Prescription-to-pay

Now we have defined the prescription details, the order moves to payment (or in eCommerce terms, checkout). The bill is put forward for payment. Payment could be split between the patient and a health insurance company. In the digital setup this is managed via payment gateway and interfaces between financial and health insurance institutes and the healthcare provider.

When the payment is received the prescription is now in a state where it can be delivered. In architecture setup, the prescription moves from the front-end applications to the back end for fulfilment.

The subscription and prescription details are mapped towards Bluefort’s Subscription Management App for Microsoft Dynamics 365 as shown below:

Fulfilment is based on payment received. The captured prescriptions details need to translate to back-office data, generating the following details:

  • Customer record for the patient (if not yet created)
  • Subscription plan covering the period or terms of the recurring prescription
  • Product or services that are part of the prescription
  • The cycle of delivery of products and services
  • Payment data via payment gateway and/or health insurance coverage

In an optimal setup, the above data is pushed from a patient portal or eCommerce site into the back-end subscription or prescription data for processing fulfilment. Once all data is validated, pushing confirmation to the patient and health care provider (or other eco-system relations) by email summarising the details above to complete the digital feedback loop of this process.

Deliver-and-receive

Now the fulfilment process starts. The subscription and prescription details drive the operational execution of delivery and services to the patient. Based on the type of prescription two aspects are required to be delivered: the actual products or medicine and accompanying services, such as a therapy visit. This process is based on the captured details of the subscription and prescription and the related cycles.

Let’s review a practical example.

John needs to recover from a wound and has an approved prescription that consist of the following products and services forming part of the treatment plan for 3 months.

  1. Pain relief medicine to be supplied weekly in a bottle of 14 tablets each
  2. Weekly nurse services to clean and dress the wound
  3. Skin-close cream, supplied every 2 weeks

The patient has been offered a 3-monthly plan, paid monthly for treatment. The payment for the first month has been made and the subscription and prescription details are in place.

From a digital point of view the following steps drive the process:

  • Based on the captured details, a business application should create an inventory forecast for the pain relief medication (to drive inventory replenishment), based on the cycle. This drives the purchase process via MRP processes;
  • The business application should create the deliveries, for example every 2 weeks in advance, based on the schedule below:

The delivery orders trigger the pick, pack and ship activities to send the product to the patient. The nurse should be scheduled to make a patient visit every week. To optimise the process, the two events could also be combined, so that the nurse delivers the products during the visit. The nurse should be scheduled accordingly.

  • In healthcare, prescription provide treatment to resolve the medical condition. The uptake of the plan can be different for each patient. Therefore, the subscription model and prescription plan and cycle might deviate along the way. This drives the requirement to provide subscription as a flexible mechanism, that can be changed during the term or treatment period. It could be stopped, since the patient might have healed or might need to be prolonged. It can also be that a treatment must be abandoned and replaced with a new prescription and treatment plan.

Let’s follow the example above and walk trough a change. In the same schedule, the red lines are now cancelled as the treatment was successful, faster than planned.

  • In this case the deliveries and nurse visits must be abandoned, and the last month’s payment can be dropped as well. If this would occur in the middle of a month, the proportionate value should be billed, during the close out of the subscription in week 9.

 

In general healthcare business processes can benefit from subscription models in other ways too. There are various models that create a much less bureaucratic event flow in healthcare when subscription models are applied.

Looking at practical examples, various countries offer subscription models, such as concierge medicine. This type of model allows patient to enrol into a medical subscription plan, providing them services and product entitlements that are part of the subscription. This eliminates billing by each item or service and creates a customer and health care provider process.

From a healthcare perspective, the billing simplification is driving efficiency and also provides scale – managing more patient and healthcare workers by eliminating unnecessary payment and financial processes.

Illustrated in the below example:

 

When the patient has prescriptions or orders products and services outside the entitlements, a charge is billed. Alternatively, the patient could be encouraged to move to the next plan, which could cover the required entitlements.

Supporting healthcare business processes is quite specific due to the nature of the eco system, patient medical records, the required approvals for prescriptions as well as the fulfilment of treatments and bringing it all together in a unified application architecture.

The key business applications of an end-to-end solution should contain the following applications:

  • Patient information portal or application used by patient, nurses and other related carers on behalf of the patient;
  • eCommerce application layer used by patient, nurses and other related carers on behalf of the patient;
  • Practitioner portal or application used by the healthcare professional authorised to create and approve regulated prescriptions;
  • Service planning application to schedule medical visits to patients;
  • Healthcare business application linked to the above applications to provide fulfilment of product deliveries, manage inventory and financial processes.

Ready to scale up your subscription business?

Contact us and take the next step here to gain the competitive edge with an automated subscription management solution.

 

JTNDc3R5bGUlMjB0eXBlJTNEJTIydGV4dCUyRmNzcyUyMiUzRSUwQSUwOS5vdXRsb29rLTM2NS1pZnJhbWUlMjAlN0IlMEElMDklMDloZWlnaHQlM0ElMjAyMDAwcHglM0IlMEElMDklN0QlMEElMEElMDklNDBtZWRpYSUyMHNjcmVlbiUyMGFuZCUyMCUyOG1pbi13aWR0aCUzQTE1OTFweCUyOSUyMCU3QiUwQSUwOSUwOS5vdXRsb29rLTM2NS1pZnJhbWUlMjAlN0IlMEElMDklMDklMDloZWlnaHQlM0ElMjAxNTAwcHglM0IlMEElMDklMDklN0QlMEElMDklN0QlMEElM0MlMkZzdHlsZSUzRQ==[tabbed_section style=”minimal_alt” alignment=”center” spacing=”default” tab_color=”Accent-Color” cta_button_style=”accent-color” icon_size=”24″][tab icon_family=”fontawesome” title=”Contact Us” id=”1618844810309-1″ icon_fontawesome=”fa fa-envelope-open-o” tab_id=”1618844810310-4″][/tab][tab icon_family=”fontawesome” title=”Set Meeting” id=”1618844810353-2″ icon_fontawesome=”fa fa-calendar” tab_id=”1618844810355-3″]JTNDaWZyYW1lJTIwY2xhc3MlM0QlMjJvdXRsb29rLTM2NS1pZnJhbWUlMjIlMjBzcmMlM0QlMjJodHRwcyUzQSUyRiUyRm91dGxvb2sub2ZmaWNlMzY1LmNvbSUyRm93YSUyRmNhbGVuZGFyJTJGYmx1ZWZvcnQxJTQwYmx1ZWZvcnQuZXUlMkZib29raW5ncyUyRiUyMiUyMHdpZHRoJTNEJTIyMTAwJTI1JTIyJTIwc2Nyb2xsaW5nJTNEJTIyeWVzJTIyJTIwc3R5bGUlM0QlMjJib3JkZXIlM0EwJTIyJTNFJTNDJTJGaWZyYW1lJTNFClick the button below to open up my calendar and find the right date and time for us to have a chat.[/tab][/tabbed_section]

Share on Socials:

Let’s chat further.

"*" indicates required fields

Consent*
This field is for validation purposes and should be left unchanged.

Related blog articles.

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.

23.07.2026 AI

Ungoverned AI Has No Business in Your System of Record

Most organisations are asking the wrong question about AI. The question is not whether AI is powerful enough to act inside an ERP. It is whether the AI is governed enough to be trusted there. There is a version of AI adoption that is happening right now across mid-market businesses that will cause significant problems in twelve to eighteen months. It is not happening because the technology is bad. It is happening because the question being asked is the wrong one. The question most organisations ask when evaluating AI for their ERP is: can it do the job? Can it handle the volume, process the data, execute the workflow? These are reasonable questions. They are also insufficient ones. Because an AI system that can do the job but cannot account for what it did, why it did it, or who authorised it is not a solution to an operational problem. It is a liability dressed as one. The right question — the one that determines whether AI in an ERP delivers value or creates exposure — is: can this AI be governed? What ungoverned AI looks like in practice Ungoverned AI is not a dramatic failure. It does not produce obviously wrong outputs in ways that are easy to catch. It produces plausible outputs in ways that are difficult to audit. A pricing decision is made. The margin is slightly wrong. There is no record of the rule that produced the price, no confidence score that would have flagged the uncertainty, no reason code that would have routed the exception to a human reviewer. The decision was made, the transaction was posted, and the audit trail ends at the output. An access permission is assigned. Six months later, an auditor asks why a finance team member has access to a module they do not use. There is no record of who authorised the assignment, what rule triggered it, or when it was last reviewed. The answer is: the system did it. A subscription contract is processed. The terms are almost right — but a renewal date was interpreted differently from what the customer agreed. The error compounds across twelve months of invoices before anyone identifies the source. None of these are catastrophic in isolation. Together, across an organisation running ungoverned AI at volume, they represent an audit risk, a margin risk, and a customer trust risk that accumulates silently until it becomes visible. Why the ERP is where governance matters most AI can be ungoverned in many places without serious consequence. An AI writing assistant that produces an imperfect first draft is corrected before the document leaves the building. An AI that summarises a meeting slightly inaccurately is corrected in the next meeting. The ERP does not work this way. In the system of record, decisions have downstream consequences that are difficult to trace and expensive to reverse. A wrong price does not stay in a draft — it goes to the invoice. A wrong access assignment does not stay in a proposal — it goes live in the production environment. A wrong subscription term does not stay in a conversation — it determines what the customer is billed for the next three years. This is why the governance standard for AI in an ERP must be higher than the governance standard for AI anywhere else in the organisation. Not because the ERP is more important than the people who work in it. Because the ERP is where the consequences of AI decisions become permanent. What a governed AI system looks like Governance is not a constraint on AI capability. It is a design principle — and when it is built in from the start rather than added afterwards, it does not reduce what AI can do. It determines what AI is trusted to do. A governed AI system in Business Central operates within a policy framework the business defines. It knows which decisions it may take autonomously — because the business has determined they are low-risk, high-volume, and well-understood. It knows which decisions require a human approval step before execution — because the business has determined that the value or the risk warrants a review. And it knows which decisions are not its to make — because the business has decided they belong entirely with a person. Within that framework, a governed AI system maintains a complete record of every action. Not a log of outputs, but a structured audit trail: what was decided, what rule applied, what confidence level the system was operating at, what the threshold was for autonomous action, and — where a human was involved — who approved it and when. That audit trail is not a retrospective report. It is a live operational output. It is what the finance controller sees when they review the AI's activity for the week. It is what the external auditor reviews when they ask how a pricing decision was made. It is what the board sees when they ask whether the AI is operating within the policy they approved. This is what it means for AI to be safe to trust with the system of record. The organisations that get this right The organisations that will use AI most effectively in Business Central are not the ones who deploy it fastest. They are the ones who define the governance framework before deployment — and build the AI into it, rather than trying to retrofit governance onto AI that is already in production. That sequence matters. A governance framework designed before AI deployment reflects what the business actually wants the AI to do. A governance framework retrofitted after deployment reflects what the AI has been doing — and the gap between the two is where the audit risk lives. The conversation about AI in ERP is accelerating. Project MIA, Microsoft's AI-assisted implementation capability announced at DynamicsMinds in May 2026, signals that AI is not arriving at the edges of the Dynamics ecosystem — it is arriving at the centre of it. The governance question is therefore not a question that can be deferred until after adoption. It is the question that should precede it. Ungoverned AI has demonstrated its value across many domains. The system of record is not one of them.

20.07.2026 AI

Why ERP Is the Hardest Place to Put AI, and Why That Matters

There is no shortage of AI tools available to businesses right now. The question worth asking is why almost none of them operate inside the ERP — and what it means that some now do. There is no shortage of AI tools available to businesses right now. Productivity assistants, document summarisers, meeting transcribers, code generators. The list grows every week. Most of them are useful. Most of them are also entirely separate from the systems that run the business. That distinction matters more than it appears. The system of record is different A CRM holds contacts. A project management tool holds tasks. A communication platform holds messages. These are valuable, but they are not the system of record. The system of record is the ERP — the environment where purchase orders are raised, invoices are generated, subscriptions are managed, prices are applied, and financial periods are closed. It is the one system where a mistake has consequences that cannot simply be undone with an undo button. This is why ERP is the hardest place to put AI — and why most AI tools stop at the boundary. When AI assists with a document or a meeting summary, the cost of an error is a correction. When AI acts inside an ERP, the cost of an error is a wrongly posted transaction, a mispriced contract, an access permission granted to the wrong person, or a financial period that closes on data nobody audited. The stakes are categorically different. The gap between recording and acting Business Central is exceptionally good at recording what happens. A purchase order arrives over budget — BC records it. A subscription renews at the wrong price — BC records it. An approval sits unactioned for eleven days — BC records that too. What BC was not designed to do is act. To reason about what has happened and decide what should happen next. To apply a rule, execute a workflow, or escalate a decision — not because someone clicked a button, but because the system understood the situation and knew what the business required. This gap between recording and acting is where significant operational cost accumulates. Finance teams spend hours each week reviewing exceptions that the system flagged but could not resolve. Consultants build workflows in Power Automate that cover eighty percent of cases and break on the other twenty. Managers approve changes they do not fully understand because the system gave them no context. The gap is not a people problem. The people are doing what the system requires of them. The gap is structural. Why AI in ERP requires a different standard There is a phrase worth internalising: the system of record demands a different standard of AI than any other application. An AI assistant that gets something slightly wrong in a draft email is a nuisance. An AI system that gets something slightly wrong inside the ERP is a liability. The difference is not one of degree — it is one of category. This is why the conversation about AI in ERP cannot be the same conversation as AI everywhere else. It cannot start with capability. It must start with governance. Before any AI system acts inside Business Central, there are questions that must be answered. Not as a compliance exercise, but as a practical requirement of operating in a system of record. Who approved this action? What rule triggered it? How confident was the system in its decision? What was the confidence threshold at which it proceeded automatically versus escalated for human review? And if the action turns out to be wrong — can it be reversed, and is there a complete record of what happened and why? These are not difficult questions to ask. They are, however, difficult questions to answer if the AI system was not designed with them in mind from the start. The governance question is the AI question There is a version of AI in ERP that is genuinely useful. It acts within rules the business defines. It surfaces its reasoning before high-value decisions are executed. It maintains a complete audit trail — not as a retrospective record, but as a live output of every action taken. It routes exceptions to the right person with the right context. It does not act autonomously where the business has decided it should not. This version of AI does not look like the AI tools most businesses have encountered so far. It does not ask to be trusted. It provides the evidence from which trust is earned — decision by decision, action by action, audit by audit. Building this version of AI is harder than building a productivity assistant. It requires deep integration with the ERP's data model, not a surface-level API connection. It requires the governance layer to be part of the design, not an afterthought. And it requires a company that understands both what the ERP can do and what the AI must not do without permission. Why this matters now Microsoft's announcement of Project MIA at DynamicsMinds in May 2026 is a useful signal, even if its first wave is aimed at Dynamics 365 Finance and Supply Chain Management rather than Business Central. The direction of travel is clear: AI-assisted implementation is arriving at the centre of the Dynamics ecosystem, and the pace is accelerating. BC will not be exempt from that trajectory. That acceleration makes the governance question more urgent, not less. The faster AI moves into ERP environments, the more important it becomes that the AI arriving there was designed to be auditable, governed, and safe to trust with the system of record. The companies that will benefit most from AI in Business Central are not necessarily the ones who move fastest. They are the ones who move with the right foundation — data that is clean and connected, processes that are documented, and AI that operates within guardrails the business has defined and the board can see. That is the standard that will matter. Not AI as an add-on to BC. AI as a native participant in what BC does — governed, auditable, and designed for the operational realities of mid-market businesses. The companies that get there first, and get there correctly, will be the ones that the governance conversation eventually lands on. The conversation about AI in ERP is just beginning. The question is not whether to have it. The question is whether to have it on the right terms.

10.07.2026 Payments

What CFOs Should Expect from a Modern Payment Platform

For many organizations, payments have traditionally been viewed as an operational necessity. As long as customers could pay invoices and suppliers received funds on time, the payment platform had done its job. Today's finance leaders expect much more. The modern CFO is responsible not only for financial control, but also for driving efficiency, supporting business growth, managing risk, and enabling digital transformation. Payments now influence cash flow, customer experience, forecasting, compliance, and strategic decision-making. As a result, the payment platform has evolved from a transactional tool into an important part of the finance technology stack. The question is no longer whether your business can process payments. The question is whether your payment platform is helping finance perform at its best. Finance Needs Visibility, Not Just Transactions Processing a payment is only one step in a much larger financial process. Finance teams need to understand what has been paid, what remains outstanding, when funds will settle, how cash flow is changing, and whether transactions have been accurately reflected in the ERP. If this information is fragmented across payment providers, bank portals, spreadsheets, and disconnected systems, finance loses valuable time consolidating data before it can begin analysing it. A modern payment platform should provide complete visibility across the payment lifecycle, enabling finance leaders to make faster, more confident decisions based on accurate and up-to-date information. Automation Should Extend Beyond Payment Collection Many organizations have successfully digitised customer payments while leaving the surrounding financial processes largely unchanged. Reconciliation remains manual. Settlement reports are imported separately. Exceptions require investigation. Month-end close depends on spreadsheet validation. These activities often consume more time than payment processing itself. A modern payment platform should automate the entire payment lifecycle, from transaction processing and reconciliation to financial posting and reporting. The objective is not simply faster payments, but a more efficient finance function. Integration Should Be Built In Finance teams work inside their ERP every day. When payment operations exist outside that environment, valuable information becomes fragmented and duplicate processes emerge. Modern payment platforms should integrate directly with Microsoft Dynamics 365, ensuring that payment data flows seamlessly into financial operations without requiring manual intervention or disconnected reporting. When payments become part of the ERP workflow, finance teams gain a more complete and reliable view of the business. Scalability Matters Business growth inevitably brings greater payment complexity. New legal entities, additional payment providers, international expansion, subscription billing, and higher transaction volumes all place increasing demands on finance operations. A payment platform should be able to support these changes without forcing organizations to redesign their financial processes every time the business evolves. Scalability is not simply about handling more transactions. It is about giving finance the confidence that its payment infrastructure can grow alongside the business. Better Payments Lead to Better Decisions Ultimately, CFOs are measured by the quality of the decisions they enable. That depends on having timely, accurate, and trusted financial information. When payment data is integrated, reconciled automatically, and visible within the ERP, finance teams spend less time gathering information and more time interpreting it. That shift allows finance to move beyond administration and become a strategic partner to the wider business. Looking Ahead The expectations placed on finance teams will continue to increase. Artificial intelligence, predictive analytics, real-time reporting, and automation are already reshaping the way finance operates. These technologies all depend on accurate, connected, and trusted financial data. Organizations that modernise their payment infrastructure today will be better positioned to take advantage of tomorrow's innovations while improving operational efficiency today. The Bottom Line A modern payment platform should do far more than process transactions. It should strengthen financial visibility, automate operational processes, improve governance, support business growth, and provide finance leaders with the information they need to make better decisions. For today's CFO, payments are no longer just an operational process. They are a strategic capability. Discover What's Possible with Bluefort TAPP Bluefort TAPP for Dynamics 365 helps organizations modernise payment operations by integrating payment processing, reconciliation, settlements, and financial workflows directly into Microsoft Dynamics 365 Business Central and Dynamics 365 Finance. Whether your goal is to improve financial visibility, reduce manual effort, or create a more connected finance function, TAPP provides the foundation for modern payment operations.

Bluefort is the Microsoft Cloud Partner and Authority with core competence in Subscription Management and Recurring Revenue automation for SMBs and Enterprise Business.

Direct

  • Solutions
  • Partners
  • Thinking

About

  • Company
  • Corporate News
  • Careers
  • Contact

Contact Details

Registered Address

Oratory Street, Naxxar
NXR 2504, Malta, EU.

+356 9902 8483

UK

2, Leman Street,
London E1W 9US, UK

US

Atlanta, Georgia,
United States

© 2024 Bluefort. All rights reserved.
Copyright Terms Privacy
Subscription integration with Sales and eCommerceNew features released for LISA in Dynamics 365 Finance and Supply Chain Man...
Scroll to top
Bluefort is the Microsoft Cloud Partner and authority in Subscription Management and Recurring Revenue automation for SMBs and Enterprise Business.
info@bluefort.io
Registered Address
Oratory Street, Naxxar NXR 2504, Malta, EU. +356 9902 8483
UK Office
2, Leman Street, London E1W 9US, UK
Quick Links
  • Solutions
    • Business Central
    • LISA Enterprise
    • Industry – TAPP
  • Resources
    • Blog
    • Learning Portal
    • Guides
  • Pricing
  • Partners
    • Enterprise Partners
    • SMB Partners
  • Company
    • About
    • Careers
  • Contact
Product menu
  • Lisa Business
  • LISA Contract Entry
  • BC Dataverse
  • LISA Enterprise
  • TAPP
  • License Guides
Industry menu
  • SaaS / Software
  • Retail & e-Commerce
  • Memberships
  • Microsoft Partners
  • e-Learning
  • Energy Retail
info@bluefort.io
© 2026, Bluefort. All Rights Reserved.
Copyright Terms Privacy