Check which Xero organisation a finance connector actually targets

A user who can access several Xero organisations can connect more than one of them to an application. Successful authorization therefore does not, by itself, prove that the next invoice or report targets the company finance intended. Before enabling a new flow or investigating an unexpected company name, verify the application's explicit organisation mapping.

Xero's connections documentation distinguishes the connection ID from the tenantId identifying the connected tenant. It also returns a tenant name for display. These fields serve different purposes. The integration owner should explain which identifier chooses the accounting organisation and how that identifier is associated with the company's own entity or store record.

Begin with the intended legal business and accounting file, then inspect the corresponding connection through authorized access. Do not select an organisation merely because it is the first entry in a returned list or its name resembles a familiar trading name. Establish the actual relationship with the person responsible for those books.

Keep an approved mapping of the internal entity, Xero organisation name, tenant identifier and relevant connection status. Include who confirmed it and when. Names help people recognize the destination, while the technical identifier establishes the integration's target. Preserve both so a renamed organisation does not become an unexplained new destination.

Keep access and refresh tokens in the application's authorized secret-management arrangement. They do not belong in the finance mapping spreadsheet, screenshots or support messages. Xero describes tokens, tenant IDs and connection IDs as separate elements of the integration. A review can verify their correct association without copying reusable credentials into the evidence record.

Preserve historical destination references when a connection is intentionally retired. Refund investigations, invoice corrections or later reporting questions may still need to establish where an earlier operation occurred. Mark the mapping inactive for new work while retaining the permitted history under the records process. Removing a live connection should not erase the company's ability to explain which books received its earlier transactions.

Ask what happens when a user reconnects or adds another organisation. The application should present and preserve an intentional mapping rather than silently replace an existing destination with the newly connected entry. Record the supported change process and the owner who approves it before any affected automated posting resumes.

For the ordinary multi-organisation flow being reviewed, have the developer trace the intended tenant context into the accounting request. Xero's guidance emphasizes keeping the correct tenant ID and related credentials associated with each request, particularly when requests run concurrently. A correct company selector on screen is insufficient if the background worker later uses a different context.

Use a harmless read or an authorized nonposting test to confirm the selected organisation before exercising consequential writes. Choose distinguishable fictional records where the test environment permits them. The finance reviewer should be able to connect the selected internal entity to the returned organisation and the intended record without guessing from a common invoice number.

Include queued work, scheduled jobs and retries in the trace. A request created under one entity can run after the user switches the visible application to another. The job should retain its own approved target rather than inherit whichever entity happens to be active later. Ask the implementer to show that relationship in the actual supported architecture.

Create an authorized test plan with two clearly differentiated organisations and operations. For example, one fictional entity can request a report for record Alpha while the other requests record Beta. Run the flows in a way that exercises the relevant concurrent code path and verify that both destination and returned content remain correctly associated.

Xero's multi-tenancy guidance discusses risks from mishandled shared resources and organisation mapping. Ask the technical owner to avoid a mutable global current tenant that unrelated requests can overwrite. The review should establish the chosen implementation's isolation, rather than prescribe a particular programming pattern without examining the application.

Record the observed result with test identities and nonsecret references. Do not test by attempting to access a real organisation outside the reviewer's authority. If an actual cross-company disclosure or posting is discovered, pause the affected flow and involve the responsible security and accounting owners through the established incident process.

Preserve the incorrect mapping, affected job references and relevant destination records before making a controlled configuration change. Establish the time range during which operations may have used the wrong organisation. A repaired dropdown or tenant binding prevents future mistakes but does not identify which earlier records need attention.

Have the accountant determine the supported correction for any records already created in the wrong books. Review their status, subsequent edits and use in payments or reporting. Do not delete or recreate an entire population simply because it originated from the affected connector. Some operations may have been correctly targeted, and some incorrect records may require a formal correction trail.

Reconcile the source operations against each destination and retain a disposition for every affected item. Include unresolved outcomes and avoid replaying work whose existing result has not been established. The recovery should leave both organisations' records explainable, with the corrected integration map and the historical repair evidence linked.

Show the connected organisation and status where staff initiate or review the finance operation. A clear destination helps users catch a mismatch before they authorize consequential work. The display should come from the established mapping and remain consistent with the target carried by the background process.

Review the mapping after additions, reconnections, entity changes or relevant integration releases. Keep the acceptance focused on the changed path and the two-organisation isolation case. A dependable connector makes the destination an explicit part of each financial operation, rather than an assumption hidden behind a successful sign-in.