Dynamics GP vs QBO vs Infor CloudSuite for ERP & Core Accounting

For a controller managing 8 legal entities who needs to prevent unauthorized prior-period postings while preserving authorized adjustments, Infor CloudSuite Financials (the Lawson-based platform) delivers this through a two-tier period close model executed via Period Closing (GL199). When closing a period, the controller selects either 'Limited Close,' which prevents routine postings but can be reopened for authorized adjustments via a formal backposting workflow, or 'Final Close,' which permanently locks the period and cannot be reopened under any circumstances. The System Control module (GL01.1) enforces AP subsystem close sequencing: the AP period must be closed before the GL period can be closed, and valid entry dates are defined per period so that invoices cannot accidentally post to closed intervals. For authorized prior-period corrections under a Limited Close, only a controller-level user can activate backposting on a specific period via Backposting Control (ML12.2/GL199), enter and post the adjustment, then re-close the period; the period then displays an 'L*' audit flag confirming that backposting occurred, which satisfies an auditor's need for a documented exception trail.

For a company like yours pursuing audited financials across 8 entities, Dynamics GP uses a Fiscal Periods Setup window (Tools > Setup > Company > Fiscal Periods) where each period can be marked closed per module series: GL, AP, AR, Payroll, and others independently. Once a period is marked closed for a series, the system hard-blocks posting to that period for that series; as Microsoft's GL year-end documentation confirms, 'after a period is marked as closed, transactions can't be posted to the period unless you reopen the period.' For authorized prior-period adjustments, GP provides two mechanisms: (1) the 'Allow Posting to History' toggle in GL Setup, which permits posting to the most recent closed year when enabled, and (2) a separately configurable 13th adjusting period for isolated post-close journal entries. However, the authorization model for reopening a period is purely access-based: a user with access to the Fiscal Periods Setup window can uncheck a series, post, and re-check it, with no native approval workflow, required reason code, or in-system audit log of who authorized the reopening and why.

For a $180M company pursuing audited financials, QBO's period-close mechanism works as follows: an admin navigates to Settings > Account and Settings > Advanced > Accounting and enables 'Close the Books,' setting a closing date. Once set, any user who attempts to edit or delete a transaction dated on or before that date will either receive a warning message or be prompted to enter a shared password, depending on which option the admin selected. If someone proceeds past the warning or enters the password, the change is logged in the 'Exceptions to Closing Date' report, which records who made the change and what was altered. In QBO Advanced, custom user roles can be configured to restrict which users have the 'modify closed period' permission, so standard AP clerks or bookkeepers can be blocked from overriding the closing date password entirely, while the controller or an external CPA retains override access.

For a $180M company running 8 legal entities, Dynamics GP's Intercompany Processing module allows a centralized AP team to enter vendor invoices in a single 'originating company' database, then distribute expense amounts to one or more 'destination companies' by entering a Co. ID field in the Payables Transaction Entry Distribution window. The system automatically generates balanced due-to/due-from GL entries between entities, so each company's books remain segregated. Users can be granted access to multiple company databases via the User Access Setup window, and the intercompany relationship is configured in the Intercompany Setup window by defining each originating-destination company pair and the corresponding due-to/due-from accounts. However, after the originating company posts the AP transaction, the destination companies receive only unposted GL journal entries (batch ID 'ICTRX'), not full AP sub-ledger transactions; a user must log into each destination company database separately to post those entries. There is no single unified AP queue where a clerk can see and process invoices for all 8 entities simultaneously within one session.

For your 8-entity, 2,500-invoice-per-month shared services scenario, Infor CloudSuite Industrial's Multi-Site Management module is the relevant mechanism. The system supports a sites-and-entities architecture where each legal entity has its own chart of accounts, currency, and financial statements, and AP activity is associated with a specific site or entity at transaction time. The Voucher Builder and multi-site vouchering features allow a single user at one base site to create cross-site vouchers from PO-generated receipts across multiple target sites, and the AP Parameters form requires specifying a site group so that records from all included sites are visible for AP payments and voucher processing (Infor CloudSuite Industrial Multi-Site Implementation Guide, docs.infor.com; Copley Consulting, 'Infor ERP Multi-site Asset Management'). Inter-Site Parameters establish intercompany account relationships so that transactions between entities post the correct due-to/due-from entries automatically. However, the native module's multi-site vouchering is scoped to PO-receipt-driven vouchers; multi-site vouchering is explicitly not available for manual vouchers and adjustments (Infor CloudSuite Industrial Multi-Site Overview, csi901.inforcloudsuite.com). A centralized AP team can process invoices across entities, but the mechanism requires replication setup between sites, site-specific user access configurations, and the cross-site payment constraint that a site can only pay for orders originating from another site reporting to the same entity. The native module does not provide a unified, entity-agnostic invoice intake queue with automated entity coding suggestions; that layer is typically added via a third-party AP automation tool such as Medius, which offers a pre-packaged certified connector specifically for multi-entity CloudSuite environments.

Your scenario requires a single centralized AP team to open a vendor bill, select the correct legal entity, and have that transaction post to the right subsidiary ledger without re-keying it elsewhere. QBO cannot do this. Each of your 8 legal entities must be set up as a separate QBO company file with its own paid subscription, and there is no entity-code field on a bill entry form that routes a transaction to a different subsidiary ledger. The only mechanism QBO provides for an AP clerk to work across entities is the 'Switch company' function: the clerk must exit the current company file, select the target entity, and enter the bill fresh in that file. This is a file-by-file re-entry workflow, not a shared services model. Intuit's own community documentation confirms that 'each business or legal entity must be set up as a separate company file with its own subscription' and that AP workflows are scoped entirely within a single company file. The workaround suggested in QBO's own support threads for centralized payment scenarios is manual journal entries recorded separately in each entity's file, which replicates the spreadsheet-and-manual-reconciliation problem the buyer is trying to solve.

For a multi-entity professional services company running on Azure Active Directory today, Infor CloudSuite delivers SSO via its Infor Security Token Service (STS), which federates directly with Azure AD using SAML 2.0. The Infor Developer Portal documents this specifically: 'Infor Cloud (specifically inforSTS or Infor Security Token Service) offers the possibility of federation with the AzureAD Identity Provider,' and 'Infor's support for the SAML 2.0 protocol aligns seamlessly with the AzureAD Identity Provider federations.' Microsoft's Entra ID gallery lists Infor CloudSuite as a supported enterprise SSO application, stating that Azure AD 'supports rich enterprise-class single sign-on with Infor CloudSuite out of the box,' and a published Microsoft Learn tutorial walks through the end-to-end SAML configuration. Infor also supports just-in-time user provisioning from Azure AD, meaning users who authenticate via Azure AD and do not already have an Infor CloudSuite account are provisioned automatically on first login. Your 320 users across 8 entities would authenticate via their existing Azure AD credentials, with Infor OS acting as the SAML service provider and Azure AD as the identity provider; the Infor CloudSuite admin console's Federated Security screen is where the SAML 2.0 metadata exchange is configured.

For your organization's Azure AD SSO requirement, Dynamics GP supports organizational account authentication against Microsoft Entra ID (formerly Azure AD), but only through its web client interface. The setup requires an administrator to register the GP web client as an application in Azure AD, then configure GP Utilities to use 'Organizational Account' as the authentication type and supply the Entra domain name. Once configured, users logging into the GP web client are redirected to authenticate with their Azure AD corporate credentials, providing a single sign-on experience consistent with Office 365 and other Microsoft cloud applications. The GP user record is mapped to the Azure AD GUID, so the system validates identity against Entra ID on each web client login. However, this mechanism does not extend to the Dynamics GP desktop client: Microsoft's own documentation confirms that identity management via organizational accounts is a web client-only feature, and users on the desktop client (including those accessing GP via Citrix or Terminal Services) must authenticate separately.

Your organization runs on Azure Active Directory and needs users to authenticate to the ERP with corporate credentials, subject to Conditional Access policies and centralized user lifecycle management. QBO does not offer this mechanism. Authentication is handled exclusively through Intuit's proprietary identity system: every user must maintain a separate Intuit Account credential (email and password, verified via Intuit's own MFA flow) to access qbo.intuit.com. QBO does not accept Azure AD (Microsoft Entra ID) as an external identity provider via SAML 2.0, OIDC, or OAuth 2.0, and it does not support SCIM-based user provisioning or deprovisioning tied to Azure AD groups. Intuit's own support staff confirmed across multiple community threads that no external IdP federation of any kind is available, and even the limited Google social login that previously existed was discontinued in October 2023. Third-party identity brokers from separate vendors (such as OneLogin or Okta with a custom connector) can create a partial credential-bridging workaround, but that requires sourcing, licensing, and maintaining a product from a different vendor entirely, and it does not deliver full Conditional Access passthrough or native SCIM provisioning.