A request like “we want a warning on the invoice when a customer exceeds their credit limit” often triggers a chain of messages, specifications and waiting for an estimate. AI development of AL extensions changes that starting point: a business user can describe the need in plain language, and the system and consultant turn it into a change proposal for Microsoft Dynamics 365 Business Central. The result is not just faster code — it is a shorter path from a problem in finance or operations to a safely tested solution.
That does not mean every request should automatically become code. Business Central is the central system for accounting, purchasing, sales, projects, approvals and reporting. A small change in one process can affect permissions, dimensions, posting or integrations. That is why the real value of an AI approach lies in combining the speed of the machine with the accountability of an experienced consultant.
What AI development of AL extensions actually changes
AL is the programming language for developing extensions in Business Central. An extension adds or customises functionality without modifying the standard Microsoft code: new fields, controls, business rules, reports, API integrations or automated approval flows.
In the traditional model, the consultant first collects the request, then writes a functional specification, the developer interprets the document, builds the code and sends it back for testing. That model can be justified for large and complex projects, but for smaller operational changes it often introduces unnecessary waiting. The problem is not only the cost of development. While the request is translated between the business user, the consultant and the developer, the context of why the change was requested is easily lost.
AI can shorten that cycle. It analyses the description of the request, recognises the Business Central objects and processes the change may touch, proposes the AL structure and generates a first version of the code. The consultant then checks whether the proposal really matches the business process, whether it respects the existing architecture and whether it introduces risk into posting, approvals or reporting.
The important distinction is this: AI should not be seen as a replacement for ERP responsibility. Its strength is accelerating the analysis, preparation and development of repeatable changes. The decision about what a change is allowed to do in production is still made by people who understand the company’s business.
From a plain-language request to the test environment
A good AI process starts with a quality description, not a command like “build an extension”. The CFO, purchasing or IT do not need to know AL, but they should explain the trigger, the rule, the users and the expected outcome.
For example, instead of the request “add invoice controls”, it is more useful to state: “When an incoming invoice is entered with an amount above EUR 5,000, it must not be posted until it is approved by the head of purchasing and the finance director. The approval must remain visible on the document and in the records.” Such a request contains the business event, the threshold, the participants, the prohibited action and the control trail.
1. Analysing the process and the existing solution
Before generating code, it is necessary to establish where the rule fits. Does the company already use the standard approval workflow? Should the amount be considered with or without VAT? Does the threshold differ by dimension, sector, location or cost type? Can the user change the invoice after the first approval?
These questions are not a delay. They prevent the wrong extension from being built quickly. AI can suggest relevant tables, pages and events in the standard application, while the consultant checks whether it is better to adapt the existing workflow or develop a separate rule.
2. A solution proposal before writing code
Before development starts, there should be a clear proposal: which fields are added, when the validation runs, who receives the approval request, what the user sees when the rule is not met and how the change is tested. For an incoming-invoice request, this can mean an additional approval status, a check before posting and a record of who decided what and when.
This step is especially important for managers. They do not have to review every AL function, but they must confirm that the business rule is interpreted correctly. Only then does code become a means of enforcing the agreed control, not a technical experiment.
3. Generating AL code and automated checks
Once the solution is confirmed, AI prepares the AL extension: objects, table or page extensions, event subscribers, validations and possibly tests. This can significantly reduce the time needed for the routine parts of development, especially for well-known patterns such as new fields, control messages, document extensions or integration with approvals.
Still, generated code is not automatically ready for production. Compilation, compatibility with the Business Central version, object names, permissions and behaviour in existing processes all need to be checked. Code that technically works can still be business-wrong if, for example, it blocks the posting of documents that should not be covered by the rule.
4. Testing, review and a controlled release
The extension is first published to a test environment. There, realistic scenarios are walked through: an invoice below the threshold, an invoice above the threshold, a rejected approval, an amount changed after approval, a user without the required permission and, where relevant, cancellation or correction of the document.
The consultant then reviews the code and the test results. Holy BC Agent was designed exactly for this way of working: AI accelerates the analysis and the build, while expert consultants validate every change before production. The company keeps an overview of what is changing, why it is changing and who approved the change.
Where AI brings business value fastest
The biggest effect usually comes from frequent, clearly defined changes that used to wait for a development slot. In finance these can be pre-posting controls, mandatory dimension completeness, budget overrun warnings, new fields on documents and tailored views of open entries.
In purchasing, AI-supported development can connect the request status, purchase order, goods receipt and incoming invoice with more precise approval rules. Instead of finance manually checking whether an invoice has the matching order or approval, the extension can show the missing step before the document reaches posting.
Project organisations often ask for changes around contracts, budgets, resources and profitability. An example is mandatory linking of a cost to a project and project phase, with a warning when the planned budget has insufficient available funds. This is not just a technical field on a document — the quality of this control directly affects the accuracy of project reporting.
For reporting, AI can accelerate the preparation of new queries, additional columns and data-classification logic. Still, the definitions of indicators must come from the business. If finance and sales interpret “recognised revenue” differently, no amount of automatically generated code will solve the problem.
Speed is not a reason to skip change management
AI development shortens build time, but it does not remove the need for rules. On the contrary: the faster changes are generated, the more clearly the company must define who submits the request, who confirms the business rule, who tests and who approves production.
| Question | Risk without control | Practical control |
|---|---|---|
| Is the request clear enough? | Code solves the wrong problem | Confirmation of the business scenario and success criteria |
| Does the change affect posting? | Wrong data in the general ledger | Test cases with real documents |
| Are the permissions correct? | Unauthorised changes or blocked work | Review of user roles and access tests |
| Is the code maintainable? | Harder upgrades and hidden dependencies | Consultant review and documented design |
Integrations, payroll calculations, mass postings and changes affecting statutory or internal controls deserve special attention. AI can help with preparation and analysis there, but the implementation decision must be based on the complete process, including exceptions and the accountability of the process owner.
How to prepare requests for AI-supported development
Companies that get the best results do not just send an idea, but a short business scenario. It is enough to describe who performs the action, on which document, under which condition, what the system should do and what must not happen. It helps to add two or three real examples, including an exception.
For example: “When a sales rep creates a sales quote for a customer with overdue debt older than 60 days, the system should show a warning. The quote can be saved, but it cannot be converted into an order without the credit controller’s approval.” Such a description immediately opens the right questions: from which records is the debt calculated, are all related companies considered, where is the approval stored and does the rule apply to all customers.
The best AI extension is not the one with the most code. It is the one that removes a concrete bottleneck, leaves a clear decision trail and keeps working reliably when the business changes. When business users describe the need precisely and an expert team reviews the solution before production, Business Central can keep up with the pace of the company without losing control.
Want to see how Holy BC Agent builds AL extensions in your Business Central environment?