Professional services firms running Microsoft Dynamics 365 or Business Central face a specific integration challenge that firms on QuickBooks or Sage do not: the Microsoft ecosystem is broader, more configurable, and more deeply embedded in the firm’s operational infrastructure than a standalone accounting system. A PSA integration that works cleanly with a simple GL often struggles with Business Central’s dimension model, multi-company setup, or the analytical reporting layer that finance teams have built around Power BI. The right question is not which PSA integrates with Dynamics — many claim to. It is which integration architecture survives real-world configuration complexity without creating a parallel reconciliation burden that defeats its own purpose.
The Microsoft ERP Landscape for Services Firms
Microsoft’s accounting and ERP products serve different segments of the market, and the PSA integration requirements differ meaningfully between them. Business Central is the mid-market ERP: a cloud-first system that handles multi-company accounting, project accounting, multi-currency, and a flexible dimension model that replaces the rigid cost center structures of older systems. Dynamics 365 Finance is the enterprise-grade ERP: a more complex system designed for organizations with sophisticated financial reporting requirements, often deployed alongside other Dynamics 365 modules for supply chain, HR, or CRM.
Most professional services firms in the 100 to 500-person range are running Business Central, either as their primary ERP or as the accounting backbone underneath a broader Microsoft stack that includes Teams, SharePoint, and Power BI. The PSA integration for this segment needs to understand Business Central specifically — its dimension model, its company structure, its journal posting logic — not just generic ERP integration patterns.
What the PSA Integration Needs to Do for a BC Firm
The integration between a PSA and Business Central needs to handle three categories of transaction cleanly, without re-entry or manual mapping at the point of posting.
- Accounts Receivable: invoices created in the PSA post to Business Central as customer ledger entries against the correct BC company, with the client mapped to the corresponding BC customer record. Credit notes and billing adjustments follow the same path in the opposite direction.
- Accounts Payable: expense reimbursements and vendor bills processed through the PSA post as vendor ledger entries in Business Central, carrying the correct vendor reference and cost allocation.
- General Ledger: cost allocations, WIP adjustments, and period-end accruals post as journal entries to the correct GL accounts in Business Central, with the right dimensions attached so that analytical reporting in Power BI and BC’s financial reporting module receives clean, pre-segmented data.
Each transaction should be sent exactly once, with a cross-reference number that links the BC entry back to the originating PSA record. That cross-reference is what makes month-end reconciliation a lookup rather than a reconstruction — finance compares BC balances against the PSA’s reconciliation reports by reference number, not by manually matching amounts across two systems.
Dimension Mapping: The Business Central-Specific Challenge
Business Central uses dimensions — named analytical attributes attached to transactions — where older accounting systems used fixed cost center codes. A dimension might represent a business group, a department, a region, a project type, or any organizational axis the firm wants to slice financial data by. Every transaction in BC carries one or more dimension values, and those dimension values determine how the data appears in financial reports and Power BI dashboards.
This is where most PSA-BC integrations become difficult. The PSA has its own organizational structure — cost centers, practice areas, project types — that needs to map to BC dimensions in a way that is consistent, maintainable, and survives organizational changes. A PSA cost center like USA|FINANCE might map to a BC dimension combination of BUSINESSGROUP = USA and DEPARTMENT = FINANCE. Every AR, AP, and GL transaction sent from the PSA needs to carry the correct dimension values for BC to classify it correctly without a finance administrator manually correcting dimension assignments after each posting run.
The integration configuration that governs this mapping — which PSA cost center segments correspond to which BC dimension names, in what positional order, with what delimiter — is the most technically demanding part of a PSA-BC implementation. It requires someone who understands both systems’ data models, not just one of them. Firms that attempt to configure this mapping without that combined expertise typically end up with dimension gaps that surface as blank analytical attributes in Power BI reports months after go-live.
How the Subledger Model Protects Business Central’s Integrity
The architectural principle that makes a PSA-BC integration work at scale is the same one that governs the Intacct integration: the PSA operates as the project accounting subledger, holding all project-level detail, while Business Central receives summary entries that have already been validated and resolved. Individual time entries, expense line items, billing rate calculations, and inter-company allocations stay in the PSA. Business Central sees the invoice total, the cost allocation, the journal entry — not the 600 time entries that produced them.
Example: A 190-person IT consulting firm bills a client £95,000 for a completed engagement delivered by consultants across two cost centers — UK delivery and US oversight. The PSA calculates the correct billing split, applies the inter-company transfer price between the two entities, and posts a single AR entry to Business Central for the UK company and a corresponding inter-company payable to the US company. Both entries carry the correct BC dimensions for departmental and regional reporting. Finance sees two clean journal entries in BC and a reconciliation report in the PSA. No manual dimension assignment required.
This model also protects Business Central from becoming a data store for operational project information that it is not designed to hold. Project managers, resource managers, and billing coordinators work entirely in the PSA. They do not need BC access, which means finance retains full control over the BC environment without creating access management complexity or audit risk from operational staff touching the GL.
Dynamics 365 Finance: A Different Integration Challenge
For firms running Dynamics 365 Finance rather than Business Central, the integration requirements are more complex and the evaluation criteria shift. D365 Finance has its own project accounting module, advanced multi-currency capabilities, and a financial dimension model that is significantly more configurable than Business Central’s. A PSA that integrates with Business Central via a native connector may not have an equivalent connector for D365 Finance — the two systems share a Microsoft lineage but are architecturally distinct, and building a production-grade integration with D365 Finance typically requires either a Microsoft-certified connector or a middleware layer that adds its own configuration and maintenance burden.
Firms on D365 Finance should ask vendors specifically whether their integration targets D365 Finance or Business Central, and request references from firms running the same version of D365 Finance in production. A vendor who conflates the two systems in their answer — or cannot name the specific D365 Finance APIs their connector uses — is describing an integration they have not fully built.
Questions That Reveal Integration Maturity
The dimension mapping question is the single most diagnostic test for PSA-BC integration maturity. Ask any vendor the following during a demo or technical discovery call, and evaluate whether they can answer with specifics rather than generalities.
- How does your integration map PSA cost center segments to BC dimension values? The answer should name the configuration mechanism and explain what happens when a cost center segment has no corresponding BC dimension — whether the transaction fails, posts with a blank dimension, or triggers an alert.
- Show me an inter-company transaction between two BC companies, posted from the PSA, with correct dimensions on both sides. This scenario is where integrations that work in single-company demos fail in multi-company production.
- What happens to transactions in the PSA when a BC posting period is closed? The integration needs to prevent or queue transactions that would post to a closed period, not fail silently and lose the data.
- How do you handle BC API version changes when Microsoft releases a Business Central update? Business Central receives two major updates per year. An integration that is not actively maintained against those updates will break on a predictable schedule.
