D365 Finance vs Business Central for ERP & Core Accounting

For a $180M multi-entity professional services and distribution company replacing QuickBooks Enterprise, D365 Finance's Financial Dimensions framework directly addresses the need to slice data simultaneously across entity, department, service line, project, and location. Administrators define each axis as a named financial dimension: entity maps to the legal entity or a BusinessUnit dimension, department and location use standard dimension types, project uses an entity-backed dimension drawn directly from the Projects table, and service line is configured as a custom financial dimension. Financial dimensions further categorize financial transactions; dimension values become segments within the ledger account and can be used for analysis such as generating a profit and loss financial statement by dimension or a trial balance by dimension. Account Structures use the main account and financial dimensions to create rule-governed combinations; a single structure supports up to 11 segments, and advanced rules extend this further. For cross-entity reporting, the Financial Reporting add-in uses Reporting Tree Definitions: a cross-dimensional hierarchical structure based on the dimensional relationships in financial data that provides information at both the reporting unit level and summary level, with an unlimited number of reporting trees to display data in various ways. The Financial Reporting add-in lets financial professionals create, maintain, and view financial statements; it includes dimension support, so account segments or dimensions are immediately available without additional configuration steps. Organization hierarchies containing legal entities or financial dimensions can be reported on in Financial Reporting, and administrators can create multilevel hierarchies using reporting tree definitions with combinations of legal entities and dimension values.

For a $180M professional services and distribution company running 8 legal entities across the US and Canada, Business Central's dimensional reporting works as follows: every journal line and document line can carry dimension tags for department, service line, project, and location using the shortcut dimension system. When dimensions and values are set up, you can define global and shortcut dimensions on the General Ledger Setup page; these dimensions are then always available to select as fields on journal and document lines, and ledger entries, without opening the Dimensions page first. Global Dimensions are used as filters on reports, batch jobs, and XMLports — but you can use only two global dimensions, so you must choose the dimensions you use most often. Shortcut Dimensions are available as fields on journals, document lines, and ledger entries, and you can create up to eight shortcut dimensions. Slicing and dicing across those tags is done via Analysis Views: an analysis by dimensions uses a selected combination of dimensions, stored and retrieved by creating an Analysis View card. To add dimension codes beyond the four on the Dimensions FastTab of the Analysis View card, you use the Filter action — but those extra dimensions act as static filters, not active slice-and-dice axes. Financial Reporting (formerly Account Schedules) adds P&L and balance sheet row/column layouts: on the Dimensions FastTab of a financial report definition, you can define dimension filters for the report, though native filtering there is limited to the two designated global dimensions. For the buyer's entity axis specifically: the Consolidated Trial Balance report combines G/L entries from each company in a new consolidated company; the companies included become Business Units in the report, meaning entity is represented as a structural Business Unit rather than a freely filterable dimension tag within the same Analysis View. The glass ceiling here is that all five of the buyer's required axes (entity, department, service line, project, location) can be tagged on every transaction, but a single native Analysis View supports only four active dimensional axes simultaneously, and entity-level filtering in cross-entity reports works through the Business Unit consolidation structure rather than through the shared dimension filter system.

For a company running 8 legal entities with a controller buried in manual AR follow-up, D365 Finance's native Credit and Collections module addresses all three layers of this requirement without add-ons. Aging is driven by configurable Aging Period Definitions (Credit and collections > Setup > Aging period definitions), where the buyer defines custom bucket intervals (day, week, month, or ledger period) that populate the Aged Balances list page; aging snapshots can be scheduled as recurring batch jobs scoped to selected companies, meaning all 8 entities can be pulled into a shared view from a single workspace. Dunning is handled by Collection Letter Sequences: administrators configure up to five escalating letter codes, each with its own grace-day threshold relative to invoice due date (letter 1) or the prior letter's post date (letters 2 through 5), and the system automatically generates and posts the next letter in the sequence as each threshold is breached. The escalation layer is delivered by Collections Process Automation (Credit and collections > Setup > Collections process setup), which orchestrates a hierarchy of steps: pre-dunning email before due date, reminder emails, collection letter generation, and collector activity creation, all triggered by days-past-due relative to the oldest open invoice; the system respects promise-to-pay and disputed statuses, pausing automation on flagged invoices and resuming when those statuses resolve. Credit and order blocking rules (Credit and collections > Setup > Credit management setup) provide a hard-stop escalation tier: orders are automatically placed on credit hold when a customer breaches overdue-amount thresholds, credit limit percentages, or account status rules, with workflow-driven release approval. The Collections Coordinator workspace gives each AR agent a single-screen view of aged balances, open invoices, disputed items, promise-to-pay commitments, and activity history for their assigned customer pool.

For a $180M professional services company moving off QuickBooks and preparing for an audit, Business Central delivers aging reports and dunning automation natively within its Accounts Receivable module. On the aging side, Business Central provides multiple out-of-box reports: the Aged Accounts Receivables report and its modern Excel variant, which bucket outstanding customer balances into configurable time periods, show summed or detailed per-document breakdowns, and calculate the percentage of total outstanding amounts per period; a Power BI Finance app adds a back-dating variant for point-in-time analysis across dimensions. On the dunning side, the system's Reminder Terms and Levels framework lets administrators define an unlimited number of reminder levels per customer segment, each carrying its own rules for when the reminder fires, what fees and interest to charge, and what email body and attachment text to send per level; escalation is inherent: Business Central tracks the highest reminder level already issued against each open customer ledger entry and automatically advances to the next level on the next automation run. The automation layer (Automate Reminders in Collections) chains three actions: Create, Issue, and Send, all executable as a scheduled job with filters, so the entire dunning cycle runs without manual intervention. Copilot for Finance in Outlook further surfaces aged balance data and dispute/promise-to-pay fields directly inside the collector's email workflow.

For a $180M professional services company running Salesforce as its CRM, the critical distinction is that D365 Finance's primary native bidirectional sync mechanism, Dual-write, connects D365 Finance tables to Microsoft Dataverse in near-real-time, and its packaged Prospect-to-Cash solution template specifically targets Dynamics 365 Sales (Microsoft's own CRM), not Salesforce. As Microsoft's own documentation confirms, Dual-write provides tightly coupled, bidirectional integration between finance and operations apps and Dataverse: any data change in finance and operations apps causes writes to Dataverse, and any data change in Dataverse causes writes to finance and operations apps; but Salesforce sits outside this loop. To bridge Salesforce to D365 Finance, the buyer must implement a middleware layer: the Finance & Operations Application Connector enables Power Automate, Power Apps, Data Integrator, and Logic Apps to integrate with finance and operations apps, and an external application can use available triggers and actions to integrate with them. Using Power Automate or Azure Logic Apps, a Salesforce closed-won stage change can fire a trigger that calls D365 Finance OData or custom service endpoints to create a billing event; and event-driven integration patterns are supported, where business events triggered by specific processes in Dynamics 365 (such as posting a customer invoice or completing a sales order) can be captured and processed by external systems using services like Azure Event Grid or Logic Apps. However, there is no official Microsoft-built out-of-the-box connector specifically for D365 Finance and Salesforce, so the bidirectional customer master sync and closed-won-to-billing-event trigger both require a custom-configured or third-party iPaaS integration.

For this $180M, 8-entity professional services and distribution company running Salesforce as its CRM, Business Central's native CRM integration module cannot be used directly: Microsoft's own documentation explicitly states that 'Business Central integrates only with Dynamics 365 Sales,' routing all native coupling, bidirectional customer-master sync, and opportunity-to-sales-order workflows through Microsoft Dataverse as an intermediary layer, which Salesforce does not sit on. To connect Salesforce, the buyer must layer a third-party AppSource/Marketplace connector such as Celigo (prebuilt iPaaS integration on Microsoft AppSource), DBSync, or APPSeCONNECT; these connectors advertise bidirectional customer-master sync and closed-won-to-BC-sales-order automation, with billing status flowing back to Salesforce. The closed-won trigger flow typically works as follows: a Salesforce opportunity reaches 'Closed Won,' the connector fires an event that creates a BC Sales Order (and subsequently a BC invoice), and payment status syncs back to Salesforce. Sync cadence in most of these connectors is scheduled (job-queue-driven) rather than true real-time, which is consistent with how BC's own Dataverse sync operates: Microsoft Learn notes that 'the synchronization between Dataverse and Business Central is based on the scheduled job queue entries and doesn't guarantee real time data consistency between two services.'

For a $180M multi-entity company with US and Canadian legal entities needing audit-ready ASC 830 compliance, D365 Finance delivers a three-layer currency architecture: transaction currency, accounting currency (functional currency per legal entity), and a reporting currency stored simultaneously on every journal line. At period-end, administrators run the Foreign currency revaluation periodic process across the General Ledger, AR, and AP subledgers; this batch job marks open CAD-denominated balances to market using the period-end spot rate and automatically posts unrealized gain/loss entries to dedicated GL accounts. <cite index='1-13'>The Bank, AR, and AP foreign currency revaluation creates accounting entries in the General Ledger to reflect the unrealized gain or loss, ensuring that the subledgers and the general ledger can be reconciled. Realized FX gain/loss is separately triggered at payment settlement when the payment rate differs from the invoice rate: <cite index='1-23,1-24'>the system requires setup of realized gain, realized loss, unrealized gain, and unrealized loss accounts; realized gain and realized loss accounts are used when settling AR and AP transactions, while unrealized gain and unrealized loss accounts are used for revaluing open transactions and general ledger main accounts. For consolidation-layer translation compliant with ASC 830's bifurcated rate requirement, Financial Reporting applies per-account exchange rate type assignments: <cite index='22-18,22-19,22-20,22-21,22-22'>four calculation methods are available: weighted average (most often for P&L accounts), average (an alternative for P&L), current/spot rate (most often for balance sheet accounts, using the rate on or before the report date), and transaction date (used for fixed assets accounts). The Currency Translation Adjustment is explicitly computed: <cite index='21-1,21-2'>the CTA is the difference between the rates used to calculate the balance sheet accounts and the rate used for the income statement accounts, and this difference causes the balance sheet to be out of balance, which the system then routes to a designated equity account. For subsidiaries that are financially and operationally independent of the parent (the standard ASC 830 scenario), <cite index='19-5,19-6'>an appropriate account for the 'Balance account for consolidation differences' posting type is selected, capturing cumulative translation differences directly in equity as ASC 830 requires. The revaluation process can be scheduled as a batch job and maintains a full history record per legal entity and posting layer, supporting the audited-financials timeline the buyer requires.

For a $180M professional services and distribution company with Canadian entities consolidating into USD for audited financials, Business Central provides a two-layer foreign currency mechanism. At the transaction level, when you post to the general ledger using a foreign currency, Business Central converts the transaction to LCY using the currency exchange rate for the posting date. For period-end revaluation, the Adjust Exchange Rates batch job manually adjusts exchange rates for posted customer, vendor, and bank account entries and can also update other reporting currency amounts on G/L entries. The system maintains separate GL accounts for each gain/loss state: dedicated G/L accounts exist for posting unrealized currency gains and unrealized currency losses, and when the invoice is paid at the actual currency rate, the unrealized gain or loss is reversed and the realized gain or loss is posted instead, satisfying the monetary-item revaluation loop in ASC 830. For consolidation-level CAD-to-USD translation across the buyer's eight entities, if a business unit uses a different currency than the consolidated company, exchange rate methods must be specified for each account, and the Consol. Translation Method field on each account determines the exchange rate applied. The exchange rates available are Average Rate (Manual) and Closing Rate, which map to ASC 830's income-statement average rate and balance-sheet closing rate requirements. However, the Additional Reporting Currency (ACY) feature should not be used as a basis for financial statement translation because it cannot translate foreign subsidiary financial statements as part of a company consolidation; it can only prepare reports in another currency as if that currency were the company's LCY. The glass ceiling is that enforcing historical exchange rates on non-monetary accounts (inventory, fixed assets, equity contributions) per ASC 830's remeasurement rules requires manual per-account configuration discipline, and there is no documented native mechanism for automatically posting the Cumulative Translation Adjustment (CTA) to a dedicated OCI/equity account: after consolidation, intercompany eliminations are a manual process requiring the user to find transactions recorded more than once and enter general journal lines to eliminate them.