Acumatica GI Cross-Tenant Patterns

"Can we get one GI that shows data across all our tenants" is a request I get from multi-entity clients running separate tenants for separate legal entities or regional subsidiaries, and the honest first answer is: not the way you are picturing it, because a GI runs inside one tenant's context, using that tenant's login session and its CompanyID/tenant scoping. There is no native "query across tenants" mode in the GI Designer.

Why tenant isolation is not just row-level security

Branches and companies within a single tenant share a database and are separated by CompanyID discrimination that the platform applies transparently — a GI author mostly does not think about it, and cross-branch/cross-company GIs (with appropriate access rights) are entirely normal. A tenant is a different, harder boundary: multi-tenant Acumatica deployments partition data more strictly, and depending on your deployment (single database with tenant discrimination versus fully separate databases per tenant on some private-cloud setups), a session authenticated against Tenant A simply has no query path to Tenant B's data at all. A GI cannot join across that boundary because BQL never gets a connection to the other tenant's data in the first place.

What actually works: consolidate outside the GI layer

For logical same-instance tenants, the realistic patterns are:

• Per-tenant scheduled export, external consolidation. Schedule the same GI (or its OData feed) to run in each tenant context, land results in a shared external database or data warehouse table tagged with a tenant identifier column you add yourself, and build the cross-tenant view there — Power BI, a small reporting database, whatever the client already has. This is the pattern I use in nearly every case; it is boring and it works because it does not fight the platform's isolation.
• REST/OData pull from an external orchestrator. Instead of scheduling exports, have an external job (a small script, an integration platform) call each tenant's OData-exposed GI endpoint with tenant-specific credentials and merge results in memory or in a staging table. Functionally similar to the export pattern but pull-based and easier to run on demand.
• A dedicated consolidation tenant fed by integration, not by GI. For clients who genuinely need near-real-time group-level reporting, I have set up a lightweight "group" tenant that receives summarized transactions via Business Events/webhooks or a scheduled sync from each operating tenant, and then build normal, single-tenant GIs against that consolidated data. This is real integration work, not a GI trick, and I scope it accordingly.

for tenant in [KE-Co, UG-Co, TZ-Co]:
    GET https://instance.acumatica.com/odata/{tenant}/KG-SalesSummary
        Authorization: Basic {tenant-scoped credentials}
    append rows, tag with TenantCode = tenant
-- merged result lands in a staging table or Power BI dataset,
-- not in any single Acumatica GI

Setting expectations early

The number one way this goes wrong on a project is scoping "a cross-tenant dashboard" as if it were a GI task and then discovering three weeks in that it needs an integration component and an external database. I now always ask the tenant-topology question in the first conversation, before any GI design starts, specifically because the answer determines whether this is a half-day GI task or a multi-week integration project.

Wrapping up

A single GI cannot natively query across Acumatica tenants — that boundary is enforced below the BQL layer. Real cross-tenant reporting means exporting or pulling from each tenant separately and consolidating externally, or feeding a dedicated consolidation tenant via integration. Confirm your actual tenant topology before scoping this as GI work; it rarely is, on its own.