Every Business Central implementation eventually meets a requirement the system doesn’t support out of the box. The natural reaction is to start building straight away. That’s usually where avoidable rework begins.
This guide sets out a practical, repeatable seven-step framework for solving a Business Central functionality gap properly. It uses a common real-world example throughout: a client asking for prepayment functionality in the Projects (Jobs) module.
Key takeaways
- Don’t start development on an assumption. First confirm what the requirement really means for this business.
- Map the whole process end to end, then write concrete use cases and edge cases.
- Capture everything in one solution design document and get client sign-off before any code is written.
- Extend Business Central with extensions. Don’t distort standard behaviour, so upgrades stay safe.
What is a Business Central functionality gap?
A functionality gap is any business requirement that standard Business Central can’t meet through setup or configuration alone. Some gaps can be closed with a different process, some with Power Platform, and some need an extension written in AL, Business Central’s development language.
Take “prepayment” as an example. It sounds simple, but it can mean very different things: a percentage of project value or a fixed amount, one prepayment or several linked to milestones, tied to the project budget or to a separate invoicing schedule. If development starts on an assumption, a mismatch is almost guaranteed, and fixing it later costs far more than getting it right up front.
| Approach | Start coding right away | Solution design first |
|---|---|---|
| Understanding of the requirement | Assumed | Confirmed with the client |
| Edge cases | Found during testing or after go-live | Identified before development |
| Rework | High | Low |
| Upgrade risk | Often high (core changes) | Low (extension-based) |
| Budget and timeline | Hard to predict | Agreed and controlled |
Why it matters for UAE and GCC implementations
GCC businesses often have requirements that standard Business Central doesn’t cover in full, such as local tax rules, UAE e-invoicing, retention billing in construction, or group reporting across several entities. These gaps are exactly where rushed customisations cause the most pain later, during upgrades, audits or when the original developer has left.
How to solve a Business Central functionality gap: a 7-step framework
Step 1: Discuss the requirement in depth
Sit down with the client and understand the business need behind the request, not just the surface ask. Ask how the process works today, who is involved, and what a good outcome looks like. Good requirement gathering removes ambiguity before it turns into a design decision the consultant makes alone.
Step 2: Map the requirement end to end
A gap is rarely isolated. For project prepayments, that means understanding how it connects to project quotes, budgets, milestone billing, work in progress (WIP) and final invoicing. Mapping the full lifecycle prevents design gaps that only appear once development is underway.
Step 3: Define concrete use cases
Turn the requirement into specific, testable scenarios. How is a prepayment raised? How is it applied against project costs? How is it adjusted or closed? Each use case should be clear enough that a tester could walk through it in Business Central step by step.
Step 4: Build out the edge cases
This step separates a thorough design from a superficial one, and it’s the one most often skipped. Clients rarely volunteer edge cases because they’re thinking about business as usual. The consultant should raise scenarios such as partial prepayments, cancellations, multi-currency projects, prepayments larger than the project value, or milestones that move after a prepayment has been applied.
Step 5: Write a solution design document
Bring the requirement, use cases and edge cases together in one document. It becomes the shared reference between the implementation team and the client, replacing verbal agreements that drift over time. Anyone new to the project should be able to read it and understand exactly what is being built and why.
Step 6: Keep customisations away from standard behaviour
The goal is to extend Business Central, not distort it. Changing core objects or standard processes to force-fit a requirement creates upgrade risk and makes the system harder to support. Using the extension model and configuration options keeps the solution upgrade-safe for the long term.
Step 7: Get client sign-off before development starts
Only start development once the client has reviewed and approved the design. Sign-off turns the document from one side’s interpretation into a mutual agreement, and it protects both the timeline and the budget.
A practical example: project prepayments
A UAE contracting company asks for “prepayments on projects”. In the workshop, the team learns they actually need two things: a 20% advance invoice when a contract is signed, and that advance deducted proportionally from each milestone invoice. Edge cases include contract changes that raise the project value, and cancelled projects that need the advance refunded.
Because these details were confirmed before any code was written, the extension handled them from day one. There were no surprises in UAT and no expensive redesign after go-live.
Best practices checklist
- Ask “why” before “how” in every requirement workshop.
- Check standard features, configuration and Power Platform before choosing custom development.
- Write at least one edge case for every use case.
- Keep one living solution design document per gap, with a version history.
- Build as extensions only. Never modify the base application.
- Get written sign-off before development, and again after UAT.
How Mohila can help
Mohila is a Microsoft partner that implements and supports Business Central across the UAE and GCC. Our consultants run structured fit-gap workshops, write solution designs your team can sign off with confidence, and build upgrade-safe extensions. See our implementation services and our ready-made Business Central extensions.
Talk to an Expert
Facing a requirement Business Central can’t handle out of the box? Book a free 1-hour consultation with a certified Dynamics 365 consultant.
Frequently asked questions
It is a business requirement that standard Business Central cannot meet through setup or configuration alone. It may be solved with a process change, Power Platform, or an AL extension.
No. Check standard features, configuration, Microsoft AppSource apps and Power Platform first. Custom development should be the last option, not the first.
The business requirement, an end-to-end process map, use cases, edge cases, the proposed solution, and what is out of scope. It should be clear enough for someone new to the project to understand.
Extensions sit on top of the standard application, so Microsoft updates can be applied without breaking your custom logic. Changing the base application makes every upgrade riskier and more expensive.
Related reading: Implementing an ERP System: A Practical Guide and Business Central vs Finance and Operations.
