Business Central
Results data reconciled with the general ledger — delivered as an implementation project, not a settings toggle.
This one is different, and we will say so up front
Every other integration on this site is something you can switch on yourself. This one is not.
Microsoft Dynamics 365 Business Central integration is delivered as an implemented solution by Sibasi. It is a scoped consulting engagement — discovery, design, build, test, deploy, support — not a connector you enable in Monival’s settings. There is no self-serve Business Central toggle in the product, and we would rather tell you that on this page than during a procurement process.
What makes it real rather than aspirational is that Business Central and Power Platform implementation is an established Sibasi delivery practice with live nonprofit and development-sector clients, independent of Monival. The capability exists and is in production for organisations today; the engagement is how you get it.
The problem it solves
Most development organisations run results and finance as two systems that never meet:
- The M&E system knows how many people were reached, at which sites, against which indicator.
- The finance system knows what was spent, on which cost centre, against which donor and which budget line.
Nothing joins them. So when a funder asks what the cost per outcome was, or whether spending is tracking delivery, someone builds a spreadsheet that maps one to the other by hand — quarterly, from memory, and differently each time.
This matters more than it sounds. A value for money assessment is not possible without that join. Unit costs computed from re-keyed estimates rather than actual ledger expenditure are exactly the figures that do not survive scrutiny, and the efficiency question cannot be answered honestly at all.
What an implementation typically covers
Scope is set per client, but the recurring elements are:
- Dimension alignment — Business Central dimensions (fund, donor, grant, project, cost centre) mapped to Monival’s programmes, result nodes and projects, so both systems describe the same thing the same way.
- Actuals from the general ledger flowing into results reporting, so budget-versus-actual sits next to target-versus-actual rather than in a different document.
- Donor and grant structures represented consistently across both systems.
- Unit cost and cost-per-result reporting computed from real expenditure.
- Power Platform layer — Power BI models over the joined data, and Power Automate flows connecting events in one system to actions in the other.
- Handover and training, because a solution nobody in the organisation can operate is not delivered.
Who this is for
It is a substantial engagement and it does not suit everyone. It fits organisations that:
- Already run, or are moving to, Business Central as the finance system.
- Manage multiple donors or funds with real dimension complexity.
- Face value-for-money or cost-effectiveness reporting requirements they currently meet by hand.
- Have enough scale that the reconciliation work is a recurring cost rather than an afternoon.
If you are a five-person organisation with one funder, this is not your next purchase. Get your indicator definitions right and your data feed into Power BI working first.
Where to start
A scoping conversation, not a demo. What we need to understand first is your chart of accounts and dimension structure, your donor and fund reporting obligations, and where the reconciliation currently costs you time — because that is what determines whether an implementation pays for itself.
Related
- Microsoft Power Automate — the event layer between systems
- Power BI — the reporting layer over joined data
- Value for money and the 4Es — why the results-to-finance join matters