My first instinct was that 33 weeks of documented AI learning gave me more than enough material. If anything, the problem would be cutting, deciding what to leave out of a series that had covered everything from basic prompting to diagnostic frameworks to building custom tools.

So I sat down with AI and started designing.

The first couple of iterations were fine. Solid structure. Logical flow. Good exercises. The kind of workshop you would expect from someone who has been writing about AI literacy for eight months.

But something felt off. It did not feel like what would have helped me on day one of my journey.

That is when I tried something I probably should have done from the beginning. Instead of designing forward from workshop objectives, I asked AI to go backward through my own journey.

Using AI to audit your own AI journey

I loaded the context of my full series and asked AI to do something specific: identify the skills I had actually picked up along the way, not the concepts I had written about, but the working skills I demonstrated across 33 weeks. Then I asked it to flag gaps, skills that were critical to accomplishing the work I had described but that I had never named, and skills I was not using that could improve my results.

What came back was not a generic checklist of things AI can do. It was a catalog of capabilities traced through my own experience, skills I could point to specific moments where I had learned them, specific articles where I had used them, and specific failures where I had discovered them.

And it was humbling.

A couple of things jumped out immediately.

First, there were skills I use in literally every AI conversation that I had never once named as teachable skills in 33 weeks of writing. I demonstrate iterative refinement constantly, treating every AI output as a first draft I shape through dialogue, but I had never called it out as a distinct skill someone needs to learn. I just did it, and assumed readers would absorb the technique by watching.

Second, and this one stung, there were simple, practical techniques I rarely use myself despite knowing they improve results. Specifying the format you want the output in, for example. I know this works. I have seen how much more effective it makes the output. And I almost never do it. It is the AI equivalent of knowing you should stretch before running and skipping it every time.

The four skills that actually matter

When I sorted everything, 33 weeks of learned skills, documented gaps, and instinctive habits I had never named, the inventory kept consolidating. Dozens of individual techniques, but they clustered into four fundamental capabilities that everything else builds on.

Think of these as layers. Each one depends on the one before it. You cannot evaluate output you have not learned to shape. You cannot manage a working conversation if you accept whatever comes back. And you cannot think strategically with AI until the mechanics of conversation become second nature.

Skill 1: Set the Stage. Everything that happens before AI generates its first response. Context, roles, examples, format, and knowing how to break big problems into smaller ones.

Skill 2: Read It Like a Skeptic. Everything that happens after AI responds. Evaluating output against your own expertise, spotting confident nonsense, recognizing when AI is telling you what you want to hear instead of what you need to hear.

Skill 3: Work the Conversation. The rhythm of real AI work, iterating on output, managing context, knowing when to push further and knowing when to start over.

Skill 4: Think Bigger, Think Better. Using AI for strategic thinking and blind-spot detection while knowing what to protect, what to verify, and when to override your own framing.

That is it. Four skills. Everything I have written about for 33 weeks either fits inside one of these or builds on top of them.

Now let me unpack what I actually found in each one, including the gaps I discovered in my own practice.

Skill 1: Set the Stage

This is where most AI education starts and stops: write better prompts. But when I mapped the full set of skills that actually shape what AI gives you, prompting was only part of it.

The foundational shift, the one everything else depends on, is understanding that you are having a conversation, not issuing a search query. That is what I wrote about in Week 1 when my son’s advice changed everything, and what I expanded in Week 3 with the Master Improv Actor framework. Most people approach AI the way they approach Google: type a question, get an answer, move on. Until that pattern breaks, nothing else in the inventory matters.

But “it’s a conversation” is only the starting line. The skills that actually set the stage go further.

Giving context is the thinking-partner shift: telling AI who you are, what you are working on, and why it matters before asking your question. Not because AI needs your biography, but because who you are shapes what useful advice looks like. I covered this in Weeks 1 and 3, and it is the core of everything I teach about Shift 1. This one I got right.

Assigning roles is the Improv Actor concept from Week 3. Give AI a character to play. “Act as a process improvement consultant” produces fundamentally different output than asking the same question without a role. Covered well.

Then the gaps start.

Providing examples of what good looks like is one of them. I touched on this in Week 28’s production-prompting work, but I never named it a fundamental skill. It is one. When you show AI an example of the writing style you want, the analysis format you need, or the level of detail you are looking for, the output quality jumps immediately. It is the difference between telling someone “write me something professional” and handing them a document and saying “like this.”

Specifying format and constraints is the gap that surprised me most, not because I did not know about it, but because I know it works and I still skip it. Tell AI you want a bulleted list, a three-paragraph summary, a table with specific columns, a response under 200 words. The output improves dramatically. I have scattered this technique across the series without ever elevating it to the fundamental skill it is. It might be the single most practical thing you can teach someone in their first hour with AI, and I had been treating it as too simple to be worth naming.

Breaking big problems into smaller ones is the last gap in this cluster. My diagnostic framework from Week 16 does this implicitly; the whole “Review of Systems” approach is about decomposing vague frustration into examinable components. But the general technique of breaking a complex request into steps before asking AI to execute is a transferable skill I never taught as such. Your first instinct is to dump a massive question on AI and hope for the best. The skill is learning to sequence: first help me understand the problem, then help me evaluate options, then help me draft a solution.

Skill 2: Read It Like a Skeptic

This is the skill that separates people who use AI from people who use AI well. And it is where I discovered the gap between what I covered conceptually and what I practice daily.

Week 4 addressed AI limitations. Week 3’s “Yes, And” principle explained why AI tends to agree with you. Week 31 explored what happens when human experts hallucinate with the same confidence as AI.

The concepts are there. The practical skills need work.

Spotting confident nonsense is the first one. AI does not hedge when it is wrong. It delivers fabricated information with the same tone and structure as accurate information. Week 31 addressed this philosophically, the idea that humans hallucinate, too. But the practical skill of catching fabrication needs more attention than I gave it. There is a specific list of things AI is reliably bad at: basic math, counting items in a list, knowing about events after its training data ends, and, critically, admitting when it does not know something. I never compiled that list in the series. I worked around these limitations instinctively. I did not teach anyone else to do the same.

Detecting sycophancy goes beyond knowing that AI agrees with you. It is the active skill of noticing when AI is flattering your ideas instead of examining them. Given everything I wrote in Week 30 about the Knowledge Trap, how having more information does not translate to persuasive power, and Week 31 about the Expertise Paradox, this skill connects directly to the most recent arc of the series. If AI confirms your assumptions because it is architecturally inclined to agree with you, and you accept that confirmation because it feels like validation of your expertise, you have built a feedback loop that makes you more confident and less accurate at the same time.

The practical counter-skill is to make it a habit to ask AI to argue the other side, find weaknesses in your reasoning, and tell you what you might be missing. I do this reflexively now. If someone had taught me to do it explicitly in my first week, it would have saved me months of accepting mediocre output because AI told me it was great.

Checking your own framing is the deepest version of this skill, and it is the one I had not fully articulated until now. AI reflects your framing back to you. If you describe a problem as a technology problem, AI gives you technology solutions. Describe the same problem as a people problem, and you will get entirely different recommendations. The pushback exercises from earlier weeks address this partially, but the core skill, pausing to ask whether your framing might be shaping the answers you are getting, is distinct from just pushing back on AI’s output. You are pushing back on your own input.

Skill 3: Work the Conversation

If Skill 1 is how you start and Skill 2 is how you evaluate, Skill 3 is how you work, the rhythm and mechanics of real AI collaboration over the course of a conversation, across conversations, and across platforms.

This cluster contains the skill I have most consistently demonstrated without ever naming it.

Iterative refinement might be the most important unnamed skill in the entire series. Every experienced AI user does it: treat the first output as raw material, then shape it through follow-up instructions, corrections, and redirections. “That is good but make it more concise.” “Keep the structure but change the tone.” “The second section is strong, rebuild the first to match it.” I do this in every article I write, every framework I develop, every client deliverable I produce. Thirty-three weeks of demonstrating it. Zero weeks of calling it out as a skill someone needs to learn.

Context management, summarizing where you are mid-conversation, resetting when things drift, I covered in Week 8’s second pillar. Carrying context between conversations through copy-paste workflows and cross-platform transfer has been a recurring theme. Those parts of the map had labels.

Knowing when to start over did not. This is a real gap. I never addressed the skill of recognizing that a conversation has gone sideways and that a fresh start will be more productive than ten more rounds of refinement. There is a moment, experienced users know it, where the AI has accumulated enough confused context that it is working against you rather than with you. The right move is to open a new conversation, paste in a clean summary of what you actually need, and start fresh. I do this regularly. I never mentioned it.

Knowing when to stop is the twin of knowing when to start over. Diminishing returns are real. I have burned more time than I would like to admit refining output past the point of meaningful improvement, running a piece of writing through too many rounds when a few rounds was probably ninety percent of the way there. The skill of recognizing “good enough” is particularly important for busy leaders who could easily spend two hours polishing something that needed twenty minutes. Nobody teaches this because it is not exciting. But it might save more time than any other skill on the list.

Skill 4: Think Bigger, Think Better

The first three skills are about working with AI. Skill 4 is about working with AI, using it as a lens to see things you could not see before, while maintaining the judgment to protect yourself and your organization.

Using AI to find problems you have normalized is the diagnostic work from Weeks 15 and 16, the unlocking questions, the seven barriers framework, and the “Review of Systems” approach. It is the category of AI use that I believe has the most transformative potential, not solving the problems you already know about, but revealing the ones you have stopped noticing.

Using AI to pressure-test your own ideas is one I use constantly, but never named as a transferable technique. Before I present a proposal, share a recommendation, or publish an article, I run it past AI as a skeptical audience. “What is the weakest argument here? What am I assuming that might not be true? If someone wanted to tear this apart, where would they start?” It is a rehearsal for every difficult conversation and is available to anyone with a subscription and the habit of asking.

Think Before You Research is the technique from Week 26 where you design your approach collaboratively with AI before deploying it to expensive deep research modes. This is a strategic skill that saves both time and money and represents the kind of second-order thinking that develops naturally after the first three skills become habitual.

Then the safety layer, which I would argue should be taught on day one, even though it only fully makes sense after you have been working with AI long enough to feel tempted to skip it.

Knowing what not to share comes from the security tiers in Week 2. This is non-negotiable and straightforward, but people need to hear it early and often: not all AI platforms protect your data equally, and what you share in a free tier conversation might be used for training.

Understanding that AI output is a draft, not a deliverable, is the editorial board concept from Week 5. AI gives you raw material. You give it judgment, verification, and accountability. The moment you submit AI output without review is the moment you have delegated your professional reputation to a system that cannot be held responsible for what it produces.

Your Week 34 Challenge: Audit Your Own Skill Gaps

1. Rate yourself honestly against the four skills. Not “have I heard of this,” that is awareness, not literacy. The question is: do you do this consistently, without thinking about it, in your actual work? Set the Stage, Read It Like a Skeptic, Work the Conversation, Think Bigger, and Think Better. Where is your biggest gap between knowing and doing?
2. Try one unnamed skill this week. Pick the simplest one: tell AI exactly what format you want before you ask your question. “Give me this as a three-paragraph summary” or “Respond in a table with columns for pros, cons, and my suggested action.” Notice what happens to the output quality.
3. Ask AI to audit you. Share a few recent AI conversations and ask: “What skills am I using well? What am I not doing that would improve my results?” It is the same exercise I did with my series, scaled down to your own practice. The answers might surprise you.
4. Name one skill you use but have never articulated. Everyone who works with AI regularly has at least one technique they have developed instinctively but could not explain to a colleague. Name it. The act of naming makes it transferable to your team, your organization, or your own intentional practice.

The Bottom Line

Thirty-three weeks into this series, I thought I had a pretty good map of AI literacy. Building a workshop that had to fit into 90 minutes revealed that my map had skills I had never labeled and routes I had never drawn, not because I did not travel them, but because I had stopped noticing the turns.

That is not a failure of the series. It is how practitioners actually learn, by watching someone do it before anyone names what is happening. But demonstrating a skill and teaching a skill are not the same thing. The workshop forced that conversion: you cannot teach someone a skill in 90 minutes if you cannot name what the skill is.

Everything I have learned clusters into four capabilities: Set the Stage, Read It Like a Skeptic, Work the Conversation, and Think Bigger and Think Better. They build on each other in that order. And the gaps I found were not in the advanced skills, they were in the simple, practical habits that experienced users do without thinking. Specifying format. Providing examples. Knowing when to stop. Knowing when to start over.

Simple enough that they feel unworthy of an article. Foundational enough that everything else builds on top of them.

If you have been following this series, you have been watching many of these skills in action for months. Now you have names for them. And naming something is the first step to teaching it, to your team, to your organization, or to yourself on the days when you know better but skip the stretch anyway.

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: The Four Skills Behind Every AI Conversation

Read more AI and Copilot blogs.

The post AI for the Over 40 – Week 34: The Four Skills Behind Every AI Conversation appeared first on ArcherPoint.

In Business Central you extend the standard application by subscribing to events, not by editing base code. The hard part is knowing which event fires, and when — and once you know, getting from that event to working AL code without breaking your flow in and out of the editor. The Event Recorder answers the first question in about a minute. Running it through VS Code answers the second.

Start from VS Code

In VS Code, press Ctrl+Shift+P and run the AL: Open Events Recorder command. This opens the Event Recorder page without leaving your editor, so the trip from finding an event to writing its subscriber stays in one place.

You’ll still need a second surface to perform the action you’re recording — open a browser tab on the same environment, and use a sandbox, not production.

Record the action

1. In the Event Recorder page, choose Record Events > Start, then confirm.

2. In the browser tab, perform only the action you want to capture, such as posting one sales order.

3. Return to the recorder and choose Stop. The captured events appear in the order they were called.

4. Locate the event you need from the captured list of triggers and custom events.

Reading the results

Each row tells you the event name, its type, and the object that published it. Order matters: an OnBefore() event is your chance to validate or block, while an OnAfter() event is where you write follow-up logic once the standard work has succeeded. Pick the narrowest event that still sees the data you need.

Back to VS Code: from Business Central Event Recorder to AL snippet

Choose Get AL Snippet on the row you want. Business Central returns a ready-made subscriber signature that you paste straight into a codeunit in VS Code — the same editor you started from.

Three things to watch

• Nothing is saved. Recorded events vanish when you refresh or close the page. Copy what you need before you navigate away.
• Record one action at a time. A short list is a readable list. Batch several actions together and the useful event is buried.
• Not every extension point appears. The recorder shows what was raised in that run. If your scenario branches, record the branch you actually care about.

Used well, the Event Recorder turns event discovery from guesswork into a five-minute step. It keeps customizations attached to published events rather than to base code, which is what keeps them upgrade-safe.

Looking for the fundamentals first? See How to Use the Event Recorder in Dynamics NAV/BC for the basic recording workflow.

The post Event Recorder to AL Code: A VS Code Workflow in Business Central appeared first on ArcherPoint.

Sales knows what customers are ordering. Purchasing knows what is on order from suppliers. Operations knows what is happening on the plant floor, in the warehouse, or on customer projects. The problem is that those views often exist separately and sometimes tell different versions of the same story.

Full operational visibility gives your staff across the organization access to timely, trustworthy information about what is happening beyond their own department and, more importantly, how activity in one area affects another: A sales promise affects inventory. A purchasing decision affects available cash. A production delay affects customer service and revenue. An overdue receivable affects the company’s ability to invest.

That visibility is rapidly becoming a competitive advantage because it helps your company compete on the total customer experience. That means that everyone in the entire organization needs to know when a decision in one department affects them.

What is operational visibility and why does it matter?

Operational visibility is the ability to see and understand what’s happening across departments, processes, and systems using timely, connected business information. It gives decision-makers the context to understand not only what changed, but why it changed and how that change affects the rest of the organization.

Reports that are a week or more old give the business little opportunity to identify and respond to issues before they become problems. Reports and dashboards should offer real-time insights, not just numbers.

The distinction matters. A CFO doesn’t simply need to know the value of inventory; they need to understand why inventory is increasing. An operations manager doesn’t just need to know that a component is unavailable; they need to know whether it is on order, when it is expected, and which customer commitments are affected.

Visibility turns isolated data points into business context.

4 examples of operational visibility across the business

Here are four examples of what that real-time operational visibility can look like:

Suppose a salesperson receives a large order from an important customer who wants delivery in three weeks. Is that good news?

1. Sales can make promises operations can keep

Probably, but first the business needs to know whether it has the inventory, materials, capacity, and supplier commitments to deliver it.

When sales and operations share visibility, salespeople can understand product availability and fulfillment constraints before making a commitment. It also means purchasing can see the new demand, operations can assess the impact on workload, and finance can assess the potential revenue and working capital implications.

2. Finance can see why margins are changing

Suppose gross margin falls by two points.

Traditional financial reporting can identify the change, but figuring out why it happened might require finance to start asking questions. Did our material costs increase? Did sales discount the price too aggressively? Did the product mix change? Was there more overtime, scrap, expedited freight, or subcontracting?

When financial and operational information is connected, finance can move beyond reporting the variance to investigating its source.

That changes the CFO’s role from explaining last month’s numbers to helping the organization influence next month’s results.

3. Purchasing can see more than what needs to be ordered

A low inventory level might signal an obvious purchasing decision: Order more inventory.

But what if demand for the item is falling? What if another location has excess stock? What if a large quantity is already scheduled to arrive?

Better visibility enables purchasing to view demand, inventory, incoming supply, locations, and operational requirements all together.

That matters to finance as well, because every unnecessary purchase converts cash into inventory. Even a necessary purchase that arrives too late can jeopardize production or customer service.

In this situation, cross-functional visibility improves both purchasing efficiency and working-capital decisions.

4. Customer service can answer without chasing someone else

A customer calls to ask, “Where is my order?”

In a disconnected environment, answering that question might require customer service to contact the warehouse, check with purchasing, email production, or wait for someone to call back.

With better operational visibility, the employee can see the customer’s order, available inventory, shipment status, outstanding purchasing activity, and any other information necessary to provide the customer a useful answer.

That might sound trivial, but when multiplied across hundreds or thousands of customer interactions every day, faster first-contact answers greatly improve the customer experience while reducing the internal effort required to provide them.

From departmental data to cross-functional visibility

Achieving operational visibility does not mean every employee sees every piece of information. Different roles only need views of the information that affects their job performance.

The CFO wants profitability, liquidity, working capital, receivables, and forecast trends. Purchasing needs supplier, order, cost, and inventory information. Sales needs customer information, order availability, and sales performance.

The goal is a common underlying version of the business, presented in ways that help each person in the organization make better decisions.

Operational visibility means the organization spends less time finding out what is happening and more time deciding what to do about it.

How Business Central and the Power Platform improve operational visibility

Microsoft Dynamics 365 Business Central connects financial and operational transactions across functions and business applications, including finance, sales, purchasing, inventory, projects, warehousing, and manufacturing.

Business Central supports dimensions that let you analyze financial information by characteristics such as department, customer, region, product, or salesperson, helping management look beyond company-wide totals to understand where performance is coming from.

Power BI takes visibility a step further by turning data into dashboards, trends, KPIs, and interactive analysis. Microsoft currently provides Business Central Power BI apps for Finance, Sales, Purchasing, Inventory, Inventory Valuation, Manufacturing, Projects, Subscription Billing, and Sustainability.

The broader Power Platform can also help organizations act on what they see. Power Automate can trigger workflows, notifications, and approvals when conditions require attention, while Power Apps can provide purpose-built experiences for employees who may not work directly in the ERP.

Operational visibility helps businesses respond faster

Operational visibility cannot eliminate events like supplier disruptions and customer change orders, but it can minimize the time between a disruption and your company’s response.

Businesses with connected visibility can spot margin problems earlier, respond to inventory imbalances sooner, and answer customers faster. The result is a progression from data to visibility to action. And responding faster to change gives you a significant competitive advantage.

Contact ArcherPoint by Cherry Bekaert to learn how Business Central and the Power Platform can help you remain competitive with real-time visibility across the organization.

The post Operational Visibility: A Competitive Advantage for Business appeared first on ArcherPoint.

The Dynamics 365 Business Central community, consisting of developers, project managers, and consultants, collaborates across various platforms to share valuable insights. At ArcherPoint, we greatly value their dedication and expertise. To ensure widespread access to this technical knowledge, we created Developer Digest.

Where are there mutants in your AL code?

Code testing can be tricky.

If you run a test and it comes back green, does that mean everything is ok? Not necessarily.

Torben Leth recommends testing your tests: In a sandbox, delete a critical line of code from a codeunit and run your tests. The test should catch the breaking code. If it doesn’t, you haven’t really tested your code.

Introducing deliberate changes (mutants) to the code and then running your test cases against it is called “mutation testing”. Mutation testing evaluates whether the test suite effectively finds the faults in your code. Undetected mutants reveal inadequate test coverage.

Leth discusses the problem and proposes an open-source solution he calls “LethAL”, developed specifically for AL developers.

Read his blog, Your Tests All Pass. I Have Bad News, to learn more and to download LethAL.

Idempotency for BC job queue transactions with external system

An error when sending a job queue transaction from Business Central to an external system can create significant production problems if you’re not looking for it. Examples include posting to an external API or calling a payment gateway.

Depending on how you code the transaction, the external system might update properly, but the error causes the Business Central database to roll back as if nothing ever happened. The job queue will see the transaction as still pending and retry the transaction. This can lead to a duplicate operation on the external system, such as a duplicate payment or a second shipment.

By introducing idempotency, you ensure that running the same operation multiple times will not create a duplicate action on the external system if it has already taken place.

Stefano Demiliani discusses this potential problem and offers a solution in his blog, Why your Business Central job queue needs idempotent external effects when integrating external systems.

As he puts it, “Don’t assume a rolled-back AL transaction means nothing happened.”

Managing BC database indexes

New in BC 2026 Wave I is the ability for administrators to manage database indexes from the BC client, providing greater control over storage requirements and database performance.

Administrators can now view all indexes in a table, monitor index size and usage, and manage indexes across companies.

However, every INSERT, MODIFY, or DELETE operation affects your indexes, leading to increased storage requirements, slower write operations, and additional maintenance overhead.

Saurav Dhyani expands on these capabilities, along with important considerations, best practices, and an FAQ, in his blog Manage Database Index Usage in Business Central.

Accessing error information in BC

Business Central lets developers view information about the last known error, which can originate from situations such as field validation and posting routine errors.

Viewing the last error is provided by the following methods:

• System.GetLastErrorCode(): Returns the type of the last error that occurred.
• System.GetLastErrorText(): Returns the details of the last error that occurred in the debugger.
• System.GetLastErrorCallStack(): Returns the call stack from where the last error occurred.

Yun Zhu explains these methods and provides examples of their usage in his blog, Dynamics 365 Business Central: GetLastErrorCode, GetLastErrorText and GetLastErrorCallStack Methods.

Are you interested in Dynamics NAV and Business Central development? Check out our collection of NAV/BC Development Blogs.

Read “How To” blogs from ArcherPoint by Cherry Bekaert for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

The post Dynamics Business Central / NAV Developer Digest – Vol. 560 appeared first on ArcherPoint.

Today’s CFO role extends well beyond producing financial statements. Finance leaders are expected to protect liquidity, manage risk, challenge assumptions, support growth, and help the business respond more quickly as conditions change.

Deloitte’s Q4 2025 CFO Signals survey reflects that shift. Half of surveyed CFOs named digital transformation of finance as a top priority for 2026, 49% said automating processes to free employees for higher-value work was a top finance-talent priority, and 87% said AI would be very or extremely important to finance operations.

For small and mid-sized businesses, CFOs don’t need more reports; they need fewer reports that provide actionable answers.

Every finance leader already knows the importance of the income statement, balance sheet, accounts receivable aging, and other standard financial statements. But those reports are often backward-looking. A useful weekly reporting cadence should do more: Highlight changes, exceptions, and emerging risks while there is still time to act.

Here are five reports every CFO should have at hand each week:

1. Cash position and short-term cash flow forecast

Cash is the first report because every other financial decision depends on it. A weekly cash view should go beyond the current bank balance. The CFO needs to see expected collections, upcoming payments, payroll and other significant obligations, anticipated large outflows, and the projected cash position over the next several weeks.

The key is movement. Is cash building or declining? Are expected receipts slipping? Is a large payment likely to create a short-term liquidity squeeze? Are assumptions in last week’s forecast still valid?

A system such as Microsoft Dynamics 365 Business Central can consolidate receivables, payables, orders, expenses, and cash flow into a single financial environment, making it easier to forecast cash rather than simply report what is already in the bank.

Executive question: Do we have enough liquidity for what is coming next?

2. Accounts receivable and collections risk

A traditional AR aging report is useful, but a CFO needs more than a list of overdue invoices. The weekly question is whether customer payment behavior is changing.

Look at total receivables, overdue balances, major past-due accounts, aging trends, and customers whose payment patterns are deteriorating. A customer that consistently pays in 30 days and suddenly stretches to 50 can become a cash-flow issue long before the balance becomes seriously delinquent.

This is where more visual reporting becomes valuable. The Power BI Finance app for Business Central includes aged receivables analysis, average collection period reporting, and late-payment reporting, designed to help finance teams identify overdue balances, payment delays, and associated cash flow risk.

Microsoft has also expanded the Finance Power BI app with rolling 12-month receivables averages and analysis of late-payment amounts versus days delayed, which can help finance teams identify changes in customer behavior over time.

Executive question: Which customers are turning revenue into cash more slowly than we expected?

3. Revenue, gross margin, and profitability variance

Revenue alone is not enough. A business can hit its sales target and still disappoint financially if discounts increase, the product mix shifts, freight costs rise, labor costs creep upward, or lower-margin customers account for a significant share of revenue.

A weekly profitability view should help the CFO see actual results against budget or forecast, gross margin percentage, major favorable and unfavorable variances, and profitability by relevant dimensions such as product line, customer group, department, geography, or business unit.

The point is to spot changes in revenue quality before they become a month-end surprise.

Executive question: Are we making the money we expected to make on the business we are winning?

4. Working capital and inventory exposure

For product-based businesses, inventory belongs on the CFO’s weekly radar. Inventory is not simply an operational metric; it is cash that has been converted into product and has not yet returned to the business.

A weekly working-capital view should help finance see inventory value, slow-moving or excess inventory, receivables, payables, and changes in the cash conversion cycle. The goal is to identify where cash is getting trapped and whether that exposure is increasing.

This is particularly important in SMB environments where a relatively small buildup in inventory or receivables can have an outsized effect on liquidity. Rather than treating finance and operations as separate reporting worlds, a modern ERP can connect inventory, purchasing, sales, receivables, payables, and financial results so the CFO can see how operational decisions affect cash.

Executive question: Where is cash getting trapped before it comes back to us?

5. Forecast vs. actual—and what changed

The fifth report may be the most strategically important. A CFO should not only ask whether actual results differ from the forecast. The more useful question is whether the forecast itself is changing.

What has moved or changed since last week: Revenue? Margin? Costs? Collections? Inventory? A major project?

Reviewing the current forecast versus actuals, the budget versus actuals, major variances, and changes to the latest outlook helps finance distinguish temporary noise from issues that may require a decision.

This is also where AI has the potential to most meaningfully change finance work. The same Deloitte survey found that 54% of CFOs surveyed identified integrating AI agents into finance as a transformation priority, and nearly half said automation should free employees to focus on higher-value work.

The idea is not to let AI make the decisions, but to reduce the time finance spends assembling the information needed to understand the variance.

Microsoft Copilot and other AI-enabled tools can help summarize data, surface anomalies, accelerate analysis, and help finance teams move quickly from what changed to why it changed.

Executive question: What changed since the last time we looked, and does it change what we should do?

The best CFO dashboard answers five questions

The goal of weekly reporting is to ensure the CFO can answer the few questions that could materially affect decision-making:

• Do we have enough cash?
• Are customers paying us on time?
• Are we protecting our margins?
• Where is working capital getting stuck?
• What changed—and does it change our plan?

A monthly close will always matter, but in a business where conditions can change between one Monday and the next, the real advantage comes from seeing the change while there is still time to respond.

CFO reporting is only as good as the data behind it

Regardless of the type of report, it must be built from complete and trustworthy information. If the figures for cash, forecasts, sales, and inventory come from different, disconnected systems, management reporting requires weekly manual reconciliation, making the reporting process a bottleneck.

That is where the Microsoft Business Central ERP platform can be particularly useful for small and mid-sized companies.

Business Central can provide the financial and operational system of record and allows users to build financial reports directly in Business Central; Power BI can turn that information into dashboards, trends, and drill-down analysis; Power Platform can support alerts, approvals, workflows, and exception handling; and Copilot can help finance teams summarize and interpret information more quickly.

There is significant value in creating a reporting environment where the CFO can drill down from a high-level view to the underlying transaction or operational cause without waiting for someone to manually assemble the answer.

Deloitte’s research shows that finance leaders are already moving in this direction. In its Q4 2025 survey, 87% of CFOs said AI would be very or extremely important to finance operations in 2026, but the value comes from embedding AI into sound data, workflows, and operating processes rather than simply layering new technology onto old ways of working.

See what’s changing before month-end

The most valuable financial insight is the one you get while there’s still time to act. ArcherPoint can help connect your financial and operational data so your CFO can see changes in cash, margins, working capital, and forecasts sooner…and drill into what’s driving them.

Contact ArcherPoint by Cherry Bekaert to improve your financial visibility.

The post 5 Reports Every CFO Should Review Weekly—and What to Look For appeared first on ArcherPoint.

Manufacturers have always operated in uncertainty. The sources might change—tariffs, raw-material prices, supplier disruptions, labor constraints, shifting customer demand—but the operational challenge remains consistent: How quickly can the business adjust when conditions change?

Right now, that question is especially pressing. In the National Association of Manufacturers (NAM) 2026 Second Quarter Manufacturers’ Outlook Survey, 83.1% of manufacturers cited rising raw-material costs as a top business challenge, while 71.8% cited trade uncertainty. Manufacturers also expected raw material and other input costs to rise 5.8% over the following 12 months.

Deloitte reaches a similar conclusion from a broader strategic perspective. Its 2026 Manufacturing Industry Outlook advises manufacturers to prepare for multiple economic scenarios and identifies agility, increasingly complex supply chains, targeted technology investments, and workforce adaptability as key priorities. That same report cited a separate Deloitte survey of 600 manufacturing executives in which 80% said they planned to invest 20% or more of their improvement budgets in smart manufacturing initiatives, including automation, analytics, sensors, and cloud technology.

A manufacturing bottleneck is any constraint in materials, capacity, information, labor, or workflow that limits how quickly production can move. While the constraint may occur at one point in the process, its effects can ripple across scheduling, inventory, costs, delivery performance, and customer service.

Manufacturers have heard the usual list of causes of manufacturing bottlenecks before: disconnected systems, data silos, spreadsheets, manual processes, poor visibility, and outdated reporting. All of those matter, but they are usually not the bottleneck itself. Instead, they create the conditions for bottlenecks in planning, materials, capacity, production flow, and day-to-day decision-making.

While manufacturers cannot eliminate uncertainty, they can eliminate many of the operational bottlenecks that make uncertainty harder and more expensive to absorb.

1. Production planning can’t keep up with changing demand

A production plan is only as useful as its ability to respond when reality changes.

A customer increases an order. Another pushes a delivery date. A supplier extends lead time. When planning, purchasing, inventory, and production operate from different information, every change can trigger another round of spreadsheets, emails, phone calls, and manual rescheduling.

The bottleneck is inaccurate forecasting, but it is also the time it takes for changing demand to translate into an updated supply and production plan.

A modern ERP for manufacturing connects demand with inventory, bills of material, purchasing, production orders, routings, and capacity. This lets planners see the effect of changing requirements across the operation and respond earlier instead of recreating the plan every time conditions change.

They can connect production orders with demand and supply planning and can generate supply recommendations through their planning functionality. This matters because speed is often the difference between a manageable change and an expensive exception.

2. The inventory is there, but not where production needs it

Manufacturers can have too much inventory and a material shortage simultaneously. The problem is rarely total inventory alone. It is whether the right component is available in the right quantity, at the right location, when a production order needs it.

Poor inventory visibility creates familiar consequences: jobs waiting for components, emergency purchases, expedited freight, excess safety stock, incomplete orders, and cash tied up in material that is not helping production move.

A connected ERP environment gives planners and operations teams a clearer view of demand, component availability, purchasing requirements, and production needs. Production orders can bring together the finished item, its bill of materials, required components, operations, and capacity requirements, while planning tools generate replenishment recommendations from actual demand.

This visibility allows the company to carry the inventory it actually needs and know where it is. Deloitte expects sourcing challenges and supply-chain volatility to persist and argues that digital tools can help manufacturers evaluate risk, model scenarios, and respond more quickly to disruption. This becomes even more important as supply chains become more complex.

3. Capacity constraints surface too late

Even when materials are available, demand is strong, and the schedule looks reasonable, one constrained resource (a critical machine goes down, a specialized operator is unavailable, or a particular operation takes longer than expected) can determine how quickly the entire production flow can move.

This is one of manufacturing’s most important (and often least visible) bottlenecks. A modern ERP helps manufacturers model work centers, machine centers, calendars, capacity, efficiency, routings, and workload so manufacturing capacity planners can compare available capacity with the work already assigned.

These ERP solutions also help manufacturers identify capacity-constrained resources and apply finite loading to critical resources rather than assuming unlimited capacity.

The executive issue is not just making sure every machine is busy, but identifying the resource that limits throughput before it disrupts production and customer delivery.

That distinction matters. Maximizing activity at every individual resource does not necessarily maximize flow across the operation. Instead, the focus should be on keeping the overall production process moving.

4. Poor production visibility means production status stays on the shop floor

In most plants, somebody knows what is happening. But when that information lives in a supervisor’s head, on a whiteboard, in a spreadsheet, or inside a production system that finance, purchasing, customer service, and leadership cannot easily see, it’s not very useful.

Leadership teams need timely answers to questions like:

• How much was produced?
• How much material was consumed?
• Was there scrap?
• What did the job cost?

If manufacturing processes can connect production with supply planning, inventory, warehouse management, costing, purchasing, and financial information rather than leaving production activity isolated from the rest of the business, production visibility changes from a reporting exercise into an operating tool.

A modern ERP connects production activity with the rest of the business. Production orders can track material consumption, output, operation time, capacity, finished goods, and production progress, giving other functions a more current view of what is actually happening.

H2: 5. Manual processes consume skilled manufacturing labor

Manufacturers often talk about labor shortages in terms of recruiting. But another labor problem hides inside many operations: Skilled employees spend too much time compensating for disconnected processes.

The problem matters because manufacturers are still competing for specialized skills. Deloitte reports that more than a third of the manufacturing executives it surveyed identified equipping workers with the skills needed for smart manufacturing as their top workforce concern. Long hiring and training lead times make it difficult to respond quickly when manufacturing labor requirements change.

Modern ERP systems do not eliminate the need for people or judgment, but they do reduce the human effort required to move routine information from one process to another.

The objective should be to use skilled expertise for exceptions, decisions, customer needs, and process improvement, not to compensate for disconnected systems.

Bonus bottleneck: Subcontracted manufacturing becomes a blind spot

You were promised five bottlenecks, but manufacturers that rely heavily on subcontractors face one more that’s worth calling out.

Heat treating, coating, machining, finishing, assembly, and other outsourced operations may occur outside your walls, but they still affect your materials, costs, production schedule, and customer commitments.

When subcontracted operations are managed separately from production, you still need answers to basic questions: Where is the material? Has the vendor completed the operation? What does it cost? Which production order does the purchase belong to? What happens to the schedule if it is late?

A modern ERP system can help manufacturers treat subcontracting as part of the production routing, connecting subcontract work centers with vendors, production orders, purchasing, materials, and costs. Subcontracting purchase orders can remain linked to the associated production activity. If you outsource critical production steps, that connection can remove a significant blind spot.

Identify, understand, and respond

Disconnected processes can quickly turn change into firefighting. Connected operations make change manageable. That is why the value of modern ERP is not simply automation or better reporting. It is the flow of information moving with materials, demand moving into planning, planning moving into production, and production activity flowing back into the financial and operational picture.

The Deloitte 2026 Outlook reinforces this mindset. Instead of trying to predict their way out of uncertainty, manufacturers should build the agility and resilience to operate successfully across different scenarios.

No ERP system can prevent a supplier disruption, stabilize commodity prices, eliminate tariffs, or guarantee customer demand. But the right ERP can help you identify, understand, and respond to unexpected changes before they critically impact your operations.

How Business Central helps remove manufacturing bottlenecks

For many small and mid-sized manufacturers, Microsoft Dynamics 365 Business Central can provide that connected operational foundation without requiring an enterprise-scale ERP environment.

With its manufacturing capabilities, Business Central supports production BOMs, routings, production orders, work and machine centers, capacity planning, inventory, supply planning, costing, warehousing, subcontracting, purchasing, sales, and finance within the same business platform.

That makes it particularly well-suited to manufacturers whose biggest challenge is not extreme production complexity, but fragmentation between the functions required to run the business.

It is also important to recognize where Business Central might not be the right fit. Manufacturers requiring highly sophisticated finite scheduling, advanced plant-floor or MES functionality, exceptionally complex global manufacturing operations, or other specialized capabilities may need additional applications or a larger ERP platform.

Where is your manufacturing operation getting stuck?

Every manufacturer has constraints. The question is whether you can see them early enough to do something about them.

ArcherPoint helps manufacturers connect planning, inventory, production, capacity, purchasing, and financial information so they can identify bottlenecks sooner and respond before they become missed schedules, higher costs, or customer problems.

If disconnected systems or processes are slowing down your operation, contact ArcherPoint by Cherry Bekaert. Let’s talk about where your bottlenecks are and whether Business Central can help remove them.

The post 5 Manufacturing Bottlenecks Holding Your Operations Back—and How to Remove Them appeared first on ArcherPoint.

My first reaction was to laugh. Not at the prospect, at the question. After 32 weeks of working intensively with AI, studying its capabilities and limitations, building frameworks for when to use probabilistic versus deterministic systems, and documenting every breakthrough and failure along the way, the idea that AI would replace ERP felt like asking whether calculators would replace accounting. 

But then I caught myself. 

I have spent the last eight months writing about exactly this kind of moment, the moment where confidence outruns analysis. I explored this in the paradox of expertise, where I confessed that I had spent years giving clients the Microsoft answer, not because I had rigorously evaluated alternatives, but because the habit of confidence had outlasted the conditions that justified it. I wrote about the difference between lying and bullshitting, and how the most dangerous form of bad advice comes from people who genuinely believe they are right but have not bothered to check. 

Was I doing it again? Was my dismissal based on 32 weeks of earned understanding about what AI can and cannot do, or was it based on the fact that I have spent 23 years selling ERP? 

I sat with that question longer than I expected, and what I found convinced me that both things can be true. My reasoning is sound, and I owe it to the prospect, and to you, to show the work rather than just deliver the conclusion. 

So let me do what this series has always tried to do: take a question seriously, examine it honestly, and share what I actually found. 

The strongest case for “AI kills ERP” 

Before I defend ERP, let me give you the best argument against it, because if I cannot articulate why smart people are asking this question, I have no business answering it. 

The pitch goes something like this. Modern AI can read unstructured documents such as invoices, purchase orders, contracts, and emails. It can understand business context. It can apply rules. It can make decisions. It can execute actions across systems. 

If AI can read a purchase order, match it to available inventory, apply your pricing rules, generate the appropriate journal entry, and post it, why do you need a rigid, expensive ERP system built on relational database architecture that has not fundamentally changed in 30 years? 

The supporting evidence is real. AI already handles natural language queries against business data. It automates document processing. It manages approvals. It generates reports. It writes code. Startups are pitching AI-native business operations platforms that promise to do everything ERP does without the implementation pain, the consultant fees, or the change management headaches. 

The argument is essentially this: ERP is the mainframe of the 2020s. Everyone knows it will eventually be replaced. The only question is when. 

I understand why that argument is compelling, and I understand why a prospect evaluating a significant ERP investment would want someone to address it directly before writing the check. 

Here is why the argument falls apart, and why the real answer is more interesting than either yes or no. 

What ERP actually is 

Before we can ask whether AI replaces ERP, we need to agree on what ERP actually is. And I think most people, including many who use ERP every day, confuse the thing they interact with for the thing itself. 

Strip away the vendor marketing and the implementation jargon, and ERP is really three things. 

The first is a database, a structured, relational store of every transaction your business has ever executed. Orders, invoices, payments, shipments, journal entries, and inventory movements are all connected, all indexed, and all queryable. This is your system of record, the single authoritative source of what actually happened in your business. 

The second is a set of rules, the business logic that determines how transactions are processed. When you post a sales invoice, the system does not just record it. It applies posting groups to determine which general ledger accounts are affected, calculates tax based on jurisdictional rules, updates accounts receivable, adjusts the customer’s credit limit, and flows cost of goods sold to the income statement. These rules enforce consistency. The same type of transaction produces the same accounting treatment every time, regardless of who initiates it or when. 

The third is an interface, the pages, menus, fields, reports, and workflows that humans use to interact with the database and the rules. This is where you enter a purchase order, run an aging report, or approve a journal entry. 

That is it. Database, rules, interface. 

Now, here is what becomes immediately clear once you see it this way: when people say AI will replace ERP, they are really talking about the interface, and they are largely right. AI is already transforming how humans interact with business systems, and that transformation will accelerate dramatically. Natural language will replace menu navigation. AI will handle document intake. Conversational queries will replace report builders. 

But nobody, not the startups, not the vendors, not the consultants, is seriously arguing that businesses can operate without a structured database of financial transactions. Nobody is arguing that we can eliminate the rules that ensure consistent, auditable accounting treatment. Nobody is suggesting that tax calculations, posting groups, or revenue recognition schedules should be handled probabilistically. 

The “AI replaces ERP” argument, once you break it down, is really “AI replaces the interface layer of ERP.” That is not a prediction. It is already happening. It is also not a threat to ERP, it is an enhancement that makes ERP dramatically more accessible. 

The interface was always the weakest part of ERP anyway. It is what drives training costs, consulting fees, user frustration, and change management budgets. If AI can replace all of that with natural language interaction, ERP does not become less valuable. It becomes more valuable to more people, more often. 

But let me be thorough about why the database and the rules cannot be replaced, because the reasons go deeper than most people realize. 

Five walls AI cannot walk through 

1. The deterministic problem: your general ledger doesn’t need judgment 

In deterministic versus probabilistic systems of this series, I spent weeks researching the distinction between deterministic and probabilistic systems. It is the most important concept for understanding why AI and ERP serve fundamentally different purposes. Deterministic systems, like ERP, operate on Boolean logic: if this, then that, with the same input producing an identical output every time. When a general ledger entry posts, there is zero tolerance for ambiguity, and the system cannot guess debit and credit amounts. 

Probabilistic systems, like AI, calculate probability distributions. They excel at judgment, context, and handling unstructured information, but identical prompts can produce different responses. That is not a bug, it is the feature that makes AI valuable for tasks that require flexibility and interpretation. 

The question is not whether AI is powerful. It is. The question is whether probabilistic reasoning can replace deterministic processing for financial transactions that require legal, regulatory, and audit compliance, and the answer is no. Not because AI is not good enough yet. Because the fundamental architecture is wrong for the job. Your general ledger does not need judgment. It needs certainty. 

2. The system of record problem: what would a world without one look like? 

Here is a thought experiment. Forget about ERP for a moment and ask a simpler question: what would it actually look like to run a business without a system of record? 

Your CFO needs to close the books at month end. Where is “the truth”? If AI processed transactions throughout the month, interpreting invoices and making judgment calls about categorization while applying business rules probabilistically, where do you go to get a definitive answer about what happened, not what AI thinks probably happened, but what actually happened? 

Your bank wants to evaluate your creditworthiness for a line of credit and asks for financial statements. Statements are prepared from what, exactly, a collection of AI decisions that may or may not be reproducible? A conversation history? 

Your company gets audited, and the auditor wants to trace a revenue transaction from the source document to the financial statement. They need to see the original order, the shipment, the invoice, the payment, and how each step flowed through your general ledger according to consistent rules, and they need to see that the same rules applied to this transaction applied to every other transaction of the same type. Where does that audit trail live if not in a system designed specifically to maintain it? 

Tax authorities want to know how you calculated your sales tax liability for the third quarter, and the answer needs to be reproducible, because if you are audited in three years, you need to be able to demonstrate that your calculations were correct at the time they were made, not that AI would probably reach the same conclusion today. 

The “AI replaces ERP” pitch does not just require better technology. It requires reinventing the entire concept of verifiable financial truth, and it requires every regulatory body, tax authority, auditor, bank, and investor to agree that probabilistic answers are acceptable substitutes for deterministic ones. That is not a technology problem. It is a civilization problem. 

3. The context problem: the most expensive transaction in history 

This one is personal. After 32 weeks of working intensively with AI, I have learned more about context windows, token consumption, and the practical limits of AI infrastructure than I ever expected, and that experience reveals something about the “AI replaces ERP” argument that I have not seen anyone else point out. 

Consider what AI would need to know to process a single, routine purchase order in Business Central. Not a complex one, just an ordinary purchase order with three line items from a domestic vendor. 

To process it correctly, AI would need, in its context, the vendor’s master data, such as payment terms, currency, default locations, and posting groups, along with the item master data for each line item, including unit of measure, costing method, inventory posting group, general product posting group, and tax product posting group. It would also need the posting group matrix that determines which general ledger accounts get hit when this combination of vendor and item transacts, the tax setup for this jurisdiction, the dimension rules that might require cost center or department codes, the approval workflow rules that determine whether this purchase order amount triggers an approval requirement, the warehouse setup and whether this is a directed put-away location, the currency exchange rate if applicable, the current inventory levels if the system needs to check availability, any blanket order this purchase order draws against, and the vendor’s purchase price agreements or discount structures. 

That is not an exhaustive list. That is a simplified list for a routine transaction. 

Now consider that Business Central handles all of this through relational database lookups, indexed queries that retrieve exactly the data needed in milliseconds, using table relationships that have been defined once and apply consistently forever. The context is not loaded into memory for each transaction. It is structured into the system architecture. The posting group matrix does not need to be understood; it is executed. 

For AI to do the same work, every bit of that context would need to be in the conversation, and every transaction would require loading the equivalent of the entire relevant portion of your business configuration, just for one purchase order. A mid-sized company might process hundreds or thousands of transactions per day, including purchase orders, sales orders, inventory transfers, journal entries, payment applications, and bank reconciliations, each requiring its own full-context load and consuming tokens, while also requiring AI to understand relationships that ERP simply enforces. 

I have spent weeks hitting the practical limits of what AI can hold in context, which is one of the reasons I have been exploring infrastructure concepts like MCP servers and RAG systems. The idea of loading enough business context for AI to reliably process even routine transactions at enterprise scale is not just impractical today, it is architecturally absurd. You would be asking AI to rebuild, from scratch, in every conversation, what ERP maintains permanently in structured tables. 

It is the difference between asking someone to memorize your entire tax code versus looking it up in a reference book. The reference book does not need to be smart. It needs to be structured, indexed, and always available. That is what ERP is. 

4. The transactional integrity problem: What happens when step three fails? 

In ERP, I documented a critical architectural requirement that most people never think about until something goes wrong: transactional boundaries. When you post a sales shipment in Business Central, a cascade of things happen simultaneously. Inventory quantities decrease, cost of goods sold flows to the income statement, accounts receivable updates, and the customer’s available credit adjusts. If the shipment involves multiple warehouses, bin contents update, and if there is serial or lot tracking, item tracking entries are created. 

All of these things happen as a single atomic transaction. Either all of them succeed, or none of them do. If step four of a six-step process fails, the system rolls back steps one through three. Your inventory never shows as shipped, while your financials show it still in stock, and your accounts receivable never shows an amount owed, while your general ledger shows no corresponding revenue. 

This is not a feature, it is a fundamental requirement called ACID compliance, standing for atomicity, consistency, isolation, and durability. It is what prevents your business data from ending up in an inconsistent state when something goes wrong, and things go wrong constantly, from network interruptions to data validation failures, concurrent user conflicts, and timeout errors. 

AI has no concept of transactional boundaries. It does not do atomic commits, and it does not roll back. If you asked AI to process that same shipment and it successfully updated inventory but failed to post the financial transaction, you would have a discrepancy between your physical inventory and your financial records, and you might not discover it until your next physical count or audit. 

The “AI replaces ERP” pitch implicitly assumes that every transaction succeeds. Anyone who has spent time in enterprise systems knows that assumption is fantasy. The value of ERP is not just processing transactions correctly; it is maintaining data integrity when transactions fail. 

5. The shared state problem: whose version of truth are you in? 

Here is one more that is easy to overlook until you think about what it actually means to run a business with multiple people making decisions simultaneously. When a warehouse worker in Denver ships an order, the inventory change is immediately visible to the sales rep in Chicago who is checking availability for a different customer. The credit manager in New York can see the updated receivable, and the CFO pulling a cash flow report sees the projected payment. All of them are looking at the same data, in the same state, at the same time. 

ERP manages shared state across the entire organization in real time. It is the reason two salespeople cannot accidentally promise the same last unit of inventory to different customers, assuming the system is configured correctly, and it is the reason the warehouse and the general ledger agree on what is in stock. 

AI conversations are stateless by nature, and each session starts fresh. There is no persistent, shared, organization-wide state that every user sees simultaneously. Even if you connected AI to a database, you would be building an ERP system, just with different branding. 

The shared-state problem is the most underappreciated aspect of ERP. It is not glamorous, and nobody gets excited about concurrent user management and record locking, but it is what allows fifty or five hundred people to operate on the same set of business data without creating chaos, and it is completely absent from every AI-native business platform pitch I have seen. 

What this actually means 

So the prospect’s question, why should I buy ERP if AI will replace it, runs into not one objection but five: deterministic processing, system of record, context economics, transactional integrity, and shared state. Any one of these would be sufficient to argue that AI enhances ERP rather than replaces it. Together, they make the case overwhelming. 

But if I stopped here, this would just be a defensive article from an ERP consultant protecting his revenue stream, and I have spent 32 weeks trying to be more honest than that. 

The prospect’s intuition is not entirely wrong. Something fundamental is changing. They are sensing a real shift; they are just misidentifying what is being replaced. AI is coming for the interface layer, and while the pace of adoption will be governed as much by people and change management as by technology, the economic implications are significant. 

To understand what is actually happening, I need to introduce you to a 160-year-old economist who predicted all of this. 

The Jevons paradox 

In 1865, William Stanley Jevons, an English economist, published a book titled The Coal Question that documented something no one expected. Steam engines had become dramatically more fuel-efficient. Common sense said England would use less coal, since better engines using less fuel per unit of work should mean lower coal consumption. Simple math. 

Except the opposite happened. Coal consumption exploded. 

More efficient engines did not reduce demand for coal; they made coal-powered applications economically viable in contexts nobody had imagined. Factories that could not afford to run on steam suddenly could. New industries emerged, and new uses for steam power were invented. The per-unit savings were overwhelmed by the sheer volume of new applications. 

Jevons captured the principle: when you make a resource dramatically more efficient to use, you do not use less of it. You use more, sometimes exponentially more. 

This pattern has repeated throughout history. More fuel-efficient cars did not reduce total miles driven; people drove more. Energy-efficient refrigerators did not reduce energy consumption; people bought more refrigerators. Cheaper data storage did not reduce storage needs; we stored exponentially more data. 

You might have encountered the concept recently without knowing the name. When Chinese AI startup DeepSeek released a model that matched American competitors at a fraction of the cost, Microsoft CEO Satya Nadella invoked the Jevons paradox in response. His argument was that cheaper, more efficient AI would not reduce demand for computing; it would make AI viable in so many new contexts that total demand would skyrocket. 

Stanford economist Erik Brynjolfsson has been applying it to AI and jobs — specifically to the labor market. He identifies three conditions that must all be true for Jevons’ paradox to hold: the technology makes workers more productive at the task, that productivity translates into lower effective costs for the output, and demand is elastic enough that lower costs trigger significantly more consumption. 

Brynjolfsson’s favorite example is airline pilots. Jets made pilots dramatically more productive, allowing them to fly farther and faster while carrying more passengers. Did that mean we needed fewer pilots? No. Cheaper air travel meant more people flew, demand exploded, and we needed more pilots, not fewer. 

Now apply those three conditions to ERP. 

The Jevons paradox applied to ERP 

Condition 1: Does AI make people more productive at using ERP? 

Absolutely. Natural language queries against business data, AI-assisted reconciliation, automated document processing that feeds structured data into ERP transactions, and Copilot summarizing customer history before a sales call are all capabilities that make ERP more productive to use. 

In the Intake-Engine-Bridge framework, I built a framework I call Intake-Engine-Bridge, with AI as the intelligent intake layer that handles unstructured input, ERP as the deterministic engine that enforces business rules, and connectors as the bridge to external systems. That architecture makes the entire system dramatically more productive than ERP alone. 

Condition 2: Does that productivity lower the effective cost of getting value from ERP? 

This is the critical insight. The cost of getting value from ERP has never been primarily the software license. It is the training, the consulting hours, the change management, the user frustration, the reports that take three days to build, and the data that sits in the system but requires an expert to extract. 

AI drops all of those costs. When a warehouse manager can ask a question in plain English instead of learning how to build a filtered view in Business Central, the effective cost of that insight approaches zero. When an accounts payable clerk can photograph an invoice and have AI extract the data instead of manually keying every field, the cost of clean data entry drops dramatically. 

Condition 3: Is demand for ERP capability elastic? 

This is the question that determines everything. I believe the answer is overwhelmingly yes, and my evidence comes from my own experience just two weeks ago. 

Below-the-line work: Jevons’ paradox in my own inbox 

I’ve previously written about a category of work I called “below-the-line” work — analysis that would be genuinely valuable but that nobody can justify the hours to perform. I had years of weekly compliance reports sitting in my email as attachments, dozens of spreadsheets. A colleague asked how many times they had submitted late time over the past year. The data existed, and the analysis was straightforward, but I simply was not going to do it. The effort of downloading each attachment, opening each spreadsheet, consolidating the data, and building a pivot table could not be justified against everything else competing for my time. 

AI dropped the effort threshold. It took one hour, including building a Power Automate flow to extract the attachments and having Claude analyze the consolidated data, for an analysis I never would have performed. 

That is Jevons’ paradox at the individual level. I did not do less analysis when AI made it easier. I ran an analysis that wasn’t happening at all. The demand was always there, latent, suppressed by friction. Remove the friction and the demand surfaces. 

Now multiply that across every person in an organization who has questions they have stopped asking because the ERP is too hard to navigate, the report is too complex to build, or the data requires consolidation across too many sources. AI does not reduce the need for ERP data. It unlocks demand for ERP data that was always there but could not be economically accessed, and that unlocked demand requires more data in the system, more accurate data, more integrated processes, and more robust business rules, in other words, more ERP capability, not less. 

The evidence was already in this series 

What strikes me now is that I have been documenting Jevons’ paradox for 32 weeks without knowing its name. 

In revolutionizing solution design, a client project estimated at 60 hours was prototyped in 2 hours using AI-assisted development. The result was not less development, it was that a project nobody would have approved at 60 hours became obvious at two. AI made previously uneconomical development suddenly viable, which increased demand for Business Central customization. 

I introduced the concept of operational debt — problems people have stopped calling problems. The diagnostic questions I developed are essentially an inventory of latent demand, since every question people have stopped asking becomes askable when AI drops the friction. 

I built an Outlook-to-Todoist integration that did not exist, not because I was doing task management badly, but because I was not doing it at all, at least not in a way that worked. AI made it possible to build what didn’t exist, which meant more capability consumed, not less. 

The pattern is consistent: every time AI reduced the cost of doing something with my tools, I did more with those tools, not less. I never once found myself thinking, “Now that AI is helping, I need fewer systems.” I found myself thinking, “Now that AI is helping, I can finally use my systems the way they were designed to be used.” 

When the paradox does not apply, and why honesty matters here 

Jevons’ paradox is not a universal law. It has a critical precondition: demand must be elastic. When it is not, efficiency gains do not produce more consumption; they just eliminate jobs. 

Brynjolfsson’s cautionary example is farming. Tractors and modern agriculture made farmers dramatically more productive, but we can only eat so much food, and demand for food is inelastic. The result was not more farming, it was fewer farmers. Agricultural employment dropped from 40 percent of Americans in 1900 to less than two percent today. 

So the honest question becomes whether ERP is more like coal or more like food. I believe it is like coal: the business appetite for better data, faster decisions, deeper analysis, and more granular insight is effectively unlimited, currently suppressed only by friction. But I want to be transparent about why this matters. The answer determines not just whether ERP survives, but what happens to the people whose jobs revolve around it. 

The part nobody wants to talk about: jobs 

Jevons’ paradox predicts that total demand for ERP capability increases. It does not promise that every existing role survives unchanged. 

Some work gets compressed. Manual data entry, basic report generation, routine reconciliation, and simple inquiry responses, the kind where someone logs into Business Central, navigates to a page, reads a number, and reports it back, are the kind of work AI absorbs almost entirely, and it is already happening. 

Some work expands. Analysis and interpretation, exception handling, process design, and strategic decision-making informed by previously inaccessible data all fall into this category, along with analysis nobody had time for — work that was not happening because the effort threshold was too high. This is the new work that emerges when friction drops. 

Some work emerges entirely. AI-ERP integration architecture, designing the intake layers for unstructured-to-structured workflows, building the prompt frameworks that help non-technical users extract value from business data, and managing the complex interplay between probabilistic AI systems and deterministic business systems are roles that barely exist today. They will be essential within five years. 

The transition is not painless, and I will not pretend otherwise. The person whose job is 80 percent data entry and 20 percent judgment calls is in a fundamentally different position than the person whose job is 20 percent data entry and 80 percent judgment calls. Jevons’ paradox says total demand for ERP work increases, but the composition of that work shifts dramatically toward judgment, analysis, and design. 

This is why I have argued throughout this series for building AI superhumans rather than waiting for AI agents. Enhancement over replacement is not just a philosophical position; it is a practical strategy for navigating exactly this transition. The organizations that invest now in building their people’s AI literacy are the ones whose employees will be positioned for the expanded and emerging work. The organizations that wait until compression is obvious will scramble. 

What my prospect actually needs to hear 

Here is what I plan to say in that meeting. The question is not whether AI will change ERP, because it will. The technology already exists for natural language to supplement menu navigation, for AI to handle the intake of unstructured information, and for reports to be generated conversationally. But technology capability and organizational adoption are two very different timelines. We are still dealing with people, and people change at people speed, not technology speed. The interface will evolve significantly, but not overnight and not without deliberate investment to help people make the transition. 

But the engine underneath, the database that stores your financial truth, and the rules that ensure it is processed consistently, does not go away. It cannot be because the technology is not ready, but because the regulatory, legal, and financial requirements for deterministic processing are fundamental to how businesses operate. 

The analogy I would offer is that AI replacing ERP is like suggesting that, because Siri can make phone calls, we no longer need cell towers. The interface changed dramatically. The infrastructure did not go anywhere. 

What AI actually does is make ERP more valuable by dropping the friction cost of extracting that value. A 160-year-old economic paradox predicts exactly this: make a resource more efficient to use and you do not use less of it, you use dramatically more. 

So yes, invest in ERP, but invest simultaneously in AI literacy for the people who will use it, because the organizations that combine robust ERP infrastructure with AI-literate employees will not just survive this transition. They will discover capabilities they did not know they had, answer questions they had stopped asking, and extract value from their business data that was always there, just waiting for the friction to drop far enough that someone would finally look. 

The bottom line 

The prospect’s question, “Why should I buy ERP if AI is going to replace it?”, contains a prediction that gets the direction exactly backward. AI is not going to replace ERP. AI is going to make ERP so much easier to use that organizations will demand more from it than they ever have before. The friction that has been suppressing the value of business data is about to drop dramatically, and when it does, the organizations with robust ERP infrastructure and AI-literate employees will have an overwhelming advantage over those with neither. 

The real question is not whether to invest in ERP. It is whether you are simultaneously investing in the AI literacy that will allow your people to unlock the value that has been sitting in your systems all along, waiting for someone to finally ask the question. 

A 160-year-old economist already told us what happens when you make a powerful resource easier to use. We just were not listening. 

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: Why AI Won’t Replace ERP (And What It Actually Threatens) 

Read more AI and Copilot blogs.

The post AI for the Over 40 – Week 33: Why AI Won’t Replace ERP (And What It Actually Threatens) appeared first on ArcherPoint.

The fundamentals haven’t changed when it comes to selecting an ERP implementation partner: You want a partner that listens, understands your business and industry, knows your technology environment, and has a proven track record.

However, the role of the ERP implementation partner has expanded considerably.

Modern ERP environments are cloud-based, data-intensive, and deeply connected to other business systems. In addition to supporting finance and operations, they are expected to support analytics, automation, AI, and continuous improvement long after go-live.

That means product expertise and certifications aren’t enough.

Your ERP implementation partner should be able to manage ERP project risk and help you achieve the business outcomes you are investing in.

Here are eight questions executives should ask.

1. Do they understand the business outcome before they talk about the software?

This is still the most important test.

A strong ERP partner starts by understanding why you’re making the investment, what needs to change, and how you’ll define success. Technology, business processes, people, and expected outcomes should be aligned from the beginning.

Ask: Can this partner clearly explain the business problem we’re solving and how we’ll measure success?

If the conversation jumps immediately to modules, features, and configuration, consider it a warning sign.

2. Have they solved problems like ours?

Industry experience matters. But industry alone isn’t enough.

Two manufacturers or distributors can have radically different ERP requirements based on size, operating model, regulatory obligations, acquisitions, geographic reach, integrations, warehouse complexity, or multi-company operations.

Don’t stop at, “Do you know our industry?”

Ask: Have you successfully implemented this ERP for organizations with our level of operational complexity?

Check references by talking to customers whose businesses genuinely resemble yours, not just companies with impressive logos.

3. Who will actually do the work?

The team selling the project isn’t necessarily the team delivering it.

Before signing, understand who will serve as the solution architect, project leader, functional consultants, technical specialists, data leads, and integration resources. Ideally, meet some of them.

You’re not just buying a methodology or a brand. You’re buying the judgment and capabilities of the people assigned to your project.

Ask: Who will be responsible for the most critical parts of our implementation, and can we meet them before we commit?

4. Will they challenge us when necessary?

Listening matters. Blind agreement doesn’t.

Experienced ERP partners should question requirements based on outdated processes, unnecessary customizations, or the assumption that the new system must reproduce everything the old one did.

Sometimes the right answer is, “Yes, the system can do that…but we don’t think you should.”

The best partners know the difference between a process that genuinely differentiates your business and one that survives simply because “we’ve always done it that way.”

Look for a partner willing to provide judgment, not just configuration.

5. Can they architect the entire environment, not just the ERP?

ERP rarely operates alone.

Your system might need to connect with CRM, eCommerce, payroll, banks, warehouse systems, industry applications, analytics, Microsoft 365, Power Platform, data platforms, and other technologies.

Integrations, data migration, testing, application lifecycle management, security, and deployment aren’t side issues. They are fundamental to a successful implementation.

Ask: Does this partner understand how ERP fits into our broader technology and data architecture?

A partner that sees only the ERP may solve one problem while creating several others.

6. Do they have a credible governance model?

Nearly every ERP partner can show you a methodology diagram.

The more important question is how the project will actually be governed when things get difficult.

Who controls scope? Who makes the final call when business and technical teams disagree? How are risks escalated? How frequently does leadership review the project? What happens when a milestone slips?

ERP transformations require clear goals, roles, decision rights, risk management, and accountability throughout design, testing, and deployment.

Methodology matters. Decision discipline matters more.

7. Do they have a serious plan for data and adoption?

An ERP implementation project can go live on schedule and still fail to deliver its expected value.

Two common reasons are poor data and poor adoption.

Your partner should have a clear plan for data cleansing, mapping, validation, testing, ownership, and cutover. But the people side is equally important.

Ask about communication, training, process ownership, user adoption, and resistance to change.

If “change management” means little more than training users shortly before go-live, keep asking questions.

A technically sound ERP that people don’t understand, trust, or use properly won’t produce the transformation you expected.

8. Are they planning for the day after go-live?

Go-live isn’t the finish line.

Cloud ERP evolves continuously: Releases arrive regularly, business requirements change, and new opportunities emerge for integrations, analytics, automation, and AI.

So don’t ask only, “What support do you provide after go-live?”

Ask something bigger: What will our organization be capable of doing for itself two years after go-live?

A good ERP implementation partner should make you more capable, not more dependent.

That means transferring knowledge, preparing internal teams, establishing governance, planning for upgrades, measuring adoption, and creating a roadmap for continuous improvement.

Choose an ERP partner that helps you build for what comes next

An ERP implementation is too important to evaluate a partner on product expertise alone. You need a team that understands your business, challenges assumptions, manages risk, and helps you build capabilities that last well beyond go-live.

Talk with ArcherPoint by Cherry Bekaert about your ERP goals, challenges, and implementation strategy. Find out how more than 20 years of ERP experience can help you reduce risk and get more value from your transformation.

The post Choosing the Right ERP Implementation Partner: 8 Questions Executives Should Ask appeared first on ArcherPoint.

The obvious cost is the lost sale. But for manufacturers, distributors, and retailers, the real cost rarely stops there. A single stockout can ripple into expedited freight charges, disrupted production schedules, inefficient purchasing, extra customer-service work, and excess inventory sitting in the wrong place elsewhere in the business.

It also chips away at something harder to quantify: customer trust.

What is the true cost of a stockout?

More than the margin lost on one missed sale. Add up the expedited freight, the purchasing concessions, the idle labor, and the customers who quietly start buying from someone else, and a stockout that looked like a minor fulfillment problem can cost thousands. Over time, recurring stockouts can affect both operational efficiency and profitability. The true costs never show up as a single line item.

The cost of stockouts in manufacturing, distribution, and retail

For a retailer, an empty shelf means a customer might substitute another product, postpone the purchase, or shop somewhere else. Repeated stockouts can undermine loyalty, create the perception that the store is unreliable, and drive customers to a competitor.

For a distributor, stockouts can lower fill rates and lead to partial orders, backorders, split shipments, and missed service-level commitments. The distributor might also have to absorb additional transportation and handling costs to make the customer whole.

For a manufacturer, the exposure is higher. Missing a single component or ingredient can interrupt an entire production schedule. Employees and equipment might sit idle while planners reshuffle production schedules, procurement searches for alternatives, and customer delivery dates are pushed back.

Stockouts increase purchasing and expedited freight costs

When the normal replenishment process can’t keep up, purchasing has to make tradeoffs fast: pay more to a backup supplier, cut order quantities, or give up negotiated terms just to get material in the door before the line stops.

Transportation costs can also be affected. A shipment that would normally arrive as part of a scheduled truckload might suddenly require expedited ground service or air freight. A distributor might split customer deliveries rather than wait until an order is complete. A manufacturer might expedite incoming components and then expedite the finished product to preserve the customer’s delivery date.

The sale might ultimately be saved, but much of its margin can disappear in the process.

The operational costs of stockouts

Some of the most expensive stockout costs never show up on an invoice at all.

Warehouse staff spend hours managing partial orders instead of processing new ones. Planners rework production schedules rather than run the next job. Finance handles the credits, rebills, and adjustments resulting from the scramble. None of that shows up as a line item, but all of it is capacity that could have gone toward something productive.

Manufacturers carry an added risk. When a shortage forces a schedule to be rebuilt around whatever components are actually available, the result is often shorter production runs, more setups and changeovers, and downtime or overtime later to catch back up.

How stockouts affect customer loyalty and retention

A consumer who repeatedly finds an empty shelf might begin shopping elsewhere. A retailer whose distributor routinely short-ships orders might seek another source. A manufacturer that can’t consistently meet delivery commitments risks becoming a less desirable supplier.

A single stockout probably won’t destroy an important customer relationship, but a pattern of them can.

That means the financial impact shouldn’t be evaluated solely as lost sales today. Leadership should also consider the potential effect on customer lifetime value, retention, fill rates, on-time delivery, and reputation.

What causes stockouts?

The immediate problem is “not enough inventory.” But that’s oversimplifying the problem.

Organizations can have too much inventory overall and still experience frequent stockouts.

The problem is having the wrong inventory in the wrong location at the wrong time.

The reasons for this are varied: Poor demand forecasting, unexpected demand spikes, inaccurate inventory records, supplier delays, long lead times, disconnected warehouse systems, production problems, and inadequate replenishment policies.

A common problem for multi-location businesses is that inventory is located somewhere in the organization, but employees lack sufficient visibility to find or reallocate it.

Why carrying more inventory doesn’t solve the stockout problem

Businesses usually respond to recurring shortages by increasing inventory, but that creates costs of its own.

Increasing inventory ties up working capital, requires warehouse space and handling, and increases carrying costs. Plus, excess inventory can risk obsolescence, markdowns, or spoilage.

Maintaining enough inventory to satisfy every conceivable demand scenario would be prohibitively expensive for most businesses.

Organizations must balance the financial consequences of a potential stockout against the cost of carrying additional inventory.

How better inventory visibility helps prevent stockouts

Preventing stockouts starts with understanding inventory within the broader supply chain.

Teams need to know not only what is on hand, but also what’s available to promise, what’s already committed to orders, what’s on purchase orders, what’s in production or transit, and when replenishment is expected.

They also need reliable demand information.

Connecting sales history, forecasts, inventory levels, supplier lead times, purchasing, and customer orders gives planners a much clearer picture of potential shortages before they occur.

The objective is to identify the risk while there is still time to act.

How Business Central can help reduce stockouts

Stockouts will never disappear completely, but you can make them less frequent and less expensive when they do occur.

Microsoft Dynamics 365 Business Central integrates inventory, purchasing, sales, warehouse operations, manufacturing, and finance into a common ERP environment, helping organizations visualize the relationships that drive stock availability.

Businesses can use demand forecasts, planning and replenishment tools, reorder policies, safety stock levels, lead times, and availability information to improve purchasing and production decisions. Inventory visibility across locations can also help organizations determine whether products can be transferred rather than purchased unnecessarily.

For manufacturers, Business Central connects material requirements with production planning, helping planners understand how component availability affects upcoming production. Distributors and retailers can use inventory and sales data to improve replenishment and gain better insight into products that are available, committed, or expected.

Because Business Central is part of the Microsoft ecosystem, organizations can extend that information through tools such as Power BI for dashboards and analytics and Power Automate for alerts and workflows.

Most importantly, finance and operations can work from the same underlying information. That makes it easier to evaluate the tradeoffs between inventory investment, service levels, purchasing costs, and profitability.

With Business Central serving as the operational hub, manufacturers, distributors, and retailers can identify potential shortages earlier and make better-informed decisions about how much inventory to carry and where to carry it.

Contact ArcherPoint by Cherry Bekaert to learn more about how Business Central can help your company manage inventory, improve forecasting, and minimize the impact of stockouts.

The post The Hidden Costs of Stockouts and How Business Central Can Help appeared first on ArcherPoint.

The Dynamics 365 Business Central community, consisting of developers, project managers, and consultants, collaborates across various platforms to share valuable insights. At ArcherPoint, we greatly value their dedication and expertise. To ensure widespread access to this technical knowledge, we created Developer Digest.

PTE management is moving to the BC Admin Center

Per-Tenant Extensions (PTEs) are custom applications designed for a specific tenant or Business Central environment rather than being available publicly, such as applications on Microsoft’s AppSource.

Until recently, PTEs could be installed using the Extension Management page. Beginning with the Dynamics 365 Business Central 2027 wave 1 release (version 30), that function will be deprecated. Instead, users with Dynamics 365 Administrator or Dynamics 365 Business Central Administrator will be able to manage PTEs through the Business Central Admin Center. This includes uploading, upgrading, scheduling an installation, and uninstalling a PTE.

PTEs scheduled for installation from the Extension Management page are not visible from the Admin Center until after the extension is successfully installed. In the same way, PTEs scheduled for installation from the Admin Center are not visible from the Extension Management page until the PTE is successfully installed.

After 2027 wave 1 is released, PTE management will be restricted to the Admin Center.

For more on this topic, read Yun Zhu’s blog, Dynamics 365 Business Central: Upload, install, and manage PTEs in the admin center (Remove ability to upload and install PTEs from Extension Management page).

Also read Stefano Demiliani’s blog, Dynamics 365 Business Central: important changes in PTE management.

Analysis Mode helps eliminate excessive Excel exports

In Dev Digest #558, we discussed using Analysis Mode in Business Central. Mohana Yadav continues the discussion by going under the hood, providing a clear explanation of how the Analysis Mode works.

In his blog, he offers a practical tutorial and notes a few limitations worth keeping in mind. He even gives you a step-by-step guide to get you up and running in ten minutes.

Check out Mohana’s blog, Analysis Mode killed half the Excel exports on your client’s shared drive, to learn more.

Practical MB-800 guidance

MB-800 is Microsoft’s certification exam for the Dynamics 365 Business Central Functional Consultant Associate credential. It covers essential Business Central functions, such as setup (companies, security, system features), financial management (chart of accounts, bank accounts), operations (sales, purchasing, inventory), and data migration (import/export during implementation).

Stefan Šošić looks at 24 BC scenarios and walks through the logic to arrive at the correct answer from the practice material. As he puts it, “The answer is the least interesting part; what matters is the mechanics underneath.”

Check out Stefan’s blog, MB-800 Decoded: 24 Business Central Scenarios and the Reasoning Behind Each Answer, to find out more.

Also, you can review the Study guide for Exam MB-800: Microsoft Dynamics 365 Business Central Functional Consultant.

Tutorial: AI-assisted development using GitHub Copilot in VS Code

Saurav Dhyani has started a series on using GitHub Copilot in VS Code for AL developers.

In Part 1, he outlines what Copilot for Business Central AL development is and gives a core vocabulary for using Copilot.

In Part 2 of AI-assisted Development, he covers setting up VS Code, AL, and GitHub Copilot for Business Central Development.

For AL developers, this is a series worth following.

Are you interested in Dynamics NAV and Business Central development? Check out our collection of NAV/BC Development Blogs.

Read “How To” blogs from ArcherPoint by Cherry Bekaert for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

The post Dynamics Business Central / NAV Developer Digest – Vol. 559 appeared first on ArcherPoint.