Dynamics GP vs Acumatica for ERP & Core Accounting

For a $180M professional services and distribution company moving off QuickBooks, Acumatica's native AP module handles the internal side of vendor management: banking details (routing number, account number) are stored in the Vendors (AP303000) form under the Payment tab, ACH payments are processed via NACHA batch export, and 1099 accumulation and e-filing are supported natively. However, Acumatica's built-in Self-Service Portal is specifically designed for customers, not vendors, covering customer orders, cases, and contracts. There is no documented native vendor-facing portal where suppliers can self-submit W-9 forms, update their own banking details, or check payment status on demand. The gap is filled through Marketplace ISV integrations: Tipalti's integration with Acumatica provides a self-service supplier portal with payment data collection and real-time authentication, extending Acumatica's existing ERP capabilities for global payables. Through Tipalti's portal, suppliers can onboard with payment data collection, and W-9 and W-8 series tax forms are digitized, collected, and validated via a KPMG-reviewed tax engine. Suppliers enter their contact information, complete W-9 or W-8 forms, indicate their preferred payment method, and view a history of invoices paid with payment status for open invoices, reducing the need for AP staff to answer payment inquiries. For buyers who need vendor self-service without a separate ISV contract, Acumatica's native glass ceiling is the internal AP staff-operated vendor master: payment method details such as account number, routing number, and bank name are entered by internal staff on the vendor's screen, with no external portal for vendors to self-update.

For a $180M professional services and distribution company requiring vendors to self-serve W-9 submissions, banking updates, and payment status inquiries, Dynamics GP offers no native vendor-facing portal. The product's 'Self Service' user type, introduced in GP 2015 R2, is scoped exclusively to internal employees for payroll time, project time, and requisitions; it is not designed for external vendor access. The Purchasing All-in-One View window is an internal inquiry tool that allows AP staff to look up vendor payment history on a vendor's behalf, but it requires internal GP credentials and does not expose any data to the vendor directly. Vendor banking and EFT details (bank name, account, routing, SWIFT) are stored in the EFT Vendor Maintenance window and can only be updated by internal users with GP access, with a vendor approval workflow routing changes to an internal approver. Third-party ISVs such as DynamicPoint offer a SharePoint-based vendor portal that integrates with GP and explicitly covers W-9 and government form collection, ACH/payment detail updates, and payment status visibility; however, this is a separately licensed add-on, not a native GP module.

For a company with US and Canadian entities on different fiscal year-ends, Dynamics GP's per-company database architecture natively handles this requirement. Each legal entity is a separate company database, and fiscal periods are configured independently per company through the Fiscal Periods Setup window (Tools >> Setup >> Company >> Fiscal Periods). The administrator enters the number and length of each company's open fiscal periods in the Fiscal Periods Setup window and, critically, enters the first and last days of the fiscal year; the fiscal year is not limited to a calendar year and can be any length. This means a Canadian entity can run a June 30 year-end while US entities run a December 31 year-end, each closing independently without blocking the other. For consolidated reporting across mismatched fiscal year-ends, Dynamics GP relies on Management Reporter (Financial Reporting): report designers use period-based column definitions to map each entity's periods to a common reporting period, pulling GL data from each company's independently-maintained fiscal structure. Intercompany transactions post to each destination company's own open fiscal period, with information posted to the specified destination companies and a General Ledger batch created in each company, respecting that company's fiscal calendar.

For a company running US entities on a December fiscal year-end and Canadian entities on a different year-end, Acumatica addresses this through its 'Multiple Calendar Support' feature, enabled via the Enable/Disable Features form (CS100000). Once enabled, each legal entity (Company record) maintains its own independent Company Financial Calendar (GL201100), where administrators configure that entity's fiscal year start date, number of periods, and period start and end dates separately from every other company in the tenant. When Multiple Calendar Support is disabled, all companies share the master calendar structure; when it is enabled, each company's financial calendar can have its own structure, and the system generates the master calendar automatically from the company-level inputs. With the feature enabled, financial years are generated separately for each company, and the system generates the corresponding years in the master calendar automatically, preserving a coherent consolidation spine while allowing each entity to open, close, and report on its own period schedule. Period open/close status can also be managed at the company level independently, so a Canadian entity's year-end close does not block or force a simultaneous close of US entities.

For a company with 8 legal entities across US and Canada needing entity, group, and consolidated reporting, Dynamics GP delivers this through Management Reporter (MR) and its Reporting Tree building block. Management Reporter is the financial report builder linked to Dynamics GP, and its tree building block creates a hierarchical organization that enables pulling financial data across the structure. In a Reporting Tree, the Company column maps each reporting unit to a specific GP company, and the top level uses @ANY to summarize all company data; each branch then breaks down to specific companies from which data is pulled. This means an administrator can define US entity nodes under a US group summary node, Canadian entity nodes under a Canada group summary node, and a single top-level node as the full consolidated view, producing reports at all three levels from one tree definition. Management Reporter aggregates amounts from child reporting units at the parent reporting unit level, a process called rolling up the data. However, the critical gap for this buyer is intercompany elimination at each consolidation tier. GP's Intercompany Processing module tracks due-to/due-from amounts between companies via intercompany payable and receivable accounts in the GL, but automated elimination rules that fire at each MR tree node are not natively available in GP. Intercompany activity must be handled by filtering accounts and financial dimensions on a row or column definition in Financial reporting, then using a calculated column or row to remove those amounts from the consolidated total, or by setting up a separate manual elimination company. This means the US-vs-Canada group-level subtotal will show gross intercompany balances unless the buyer builds and maintains calculated elimination rows in each MR report, which is a recurring manual step rather than an automated rule applied at each hierarchy node.

For a $180M company with 8 legal entities across US and Canada, Acumatica's multi-entity architecture uses a three-tier Tenant/Company/Branch hierarchy where each company represents a distinct legal entity. The primary reporting mechanism for multi-level consolidation is the Financial Report Writer's 'Unit Set,' which defines a parent-child tree of companies and branches: a user builds a Unit Set with a US-group parent node containing the US entity children, a Canada-group parent node containing the Canadian entity children, and an ALL node at the top, so that 'user can select to print for any level from individual branch, up to entire enterprise.' Intercompany eliminations across these levels are supported via the Intercompany Accounting module, which 'flags them for elimination during consolidation,' but elimination logic must be embedded in report Row Sets rather than being automatically applied at each hierarchy node in the Unit Set tree. A dedicated Consolidation Ledger (GL304500) and Intercompany Accounting configuration (GL104500) support the overall consolidation architecture.

For a $180M professional services and distribution company needing to slice financials across entity, department, service line, project, and location simultaneously, Acumatica delivers this through two complementary mechanisms. First, the multi-segment Subaccount structure (configured via Segmented Keys, CS202000) allows the buyer to define a composite subaccount code where each segment encodes one dimension: for example, a three-segment subaccount could encode department, service line, and location on every GL transaction. As the Acumatica community documents, 'Segments allow us to use more than one of the above ideas; for example, a store could be located in a region and the store could have departments,' and 'using subaccounts along with accounts on transactions allows for more detailed reporting out of the General Ledger.' Segments allow using more than one analytical dimension simultaneously, and combining subaccounts with accounts enables detailed GL reporting. Entity is handled as a separate first-class Branch/Company field on every transaction, not as a subaccount segment. Real implementations have used 'Branches for account locations and Sub Accounts for service lines,' enabling geographic expansion via branches while maintaining consistent subaccount segments across the organization. Second, the Project Accounting module adds project as an independent fifth dimension: the project accounting functionality helps monitor and manage costs and budget, and any entered document can be associated with a specific project to ensure all project-related activity is accounted for. For reporting, the Analytical Report Manager (ARM) uses row sets, column sets, and unit sets to build cross-dimensional financial statements. To define what data will be displayed in each analytical report, the user defines the row set and column set; optionally, a unit set can be defined. A subaccount structured as Department-Line-Unit facilitates P&Ls with those dimensions across columns, and entire P&Ls for each department, line of business, or business unit. ARM data source filters apply subaccount segment masks via wildcard patterns, allowing any single segment to be isolated or wildcarded for cross-dimensional slices. Data source filters for subaccounts on ARM financial statement reports can be updated to reflect new subaccount combinations as the segment structure evolves.

For a $180M professional services and distribution company needing to slice financials simultaneously across entity, department, service line, project, and location, Dynamics GP's Analytical Accounting (AA) module is the correct mechanism. AA allows users to "enter detailed analysis information without resorting to segmental accounting" and supports setting up "unlimited analysis dimensions" with the ability to "enter analysis information for a group of analysis dimensions" — meaning all five of the buyer's required axes (entity, department, service line, project, location) can be configured as independent transaction dimensions and tagged simultaneously on a single GL distribution, with no account-code explosion. SmartLists and Excel Reports for AA transaction information display each AA dimension as a separate column, and the buyer can summarize and work with the data in Excel using pivot table functionality, enabling cross-dimensional slicing. However, "you cannot enter multidimensional analysis codes for destination company distributions" on intercompany transactions; to enter analysis information for those codes, you must view and edit the intercompany transaction in the General Ledger of the destination company — meaning cross-entity AA tagging on intercompany flows requires a manual, per-entity step rather than a single consolidated entry. This breaks the end-to-end process for a buyer who needs simultaneous five-dimension tagging to flow automatically across all 8 entities.