agent wrote adjustments to the wrong entity after the entity-switch call faile

Not specified by the original author.

TL;DR

A silent entity-switch failure leaves the agent authenticated to entity A while believing it is in entity B, so every adjustment lands in the wrong books. Inventory the agent's writes since the switch attempt and reverse each one in the wrong entity, then repost correctly in the right entity. Fix the switch call to return and assert the active entity from the API response, and gate every write on that assertion, so a failed switch stops the job instead of misposting.

agent wrote adjustments to the wrong entity after the entity-switch call failed silently

Use this when

• Adjustments intended for one entity appear in another entity's ledger.
• The agent's log shows an entity switch with no confirmation of the new active entity.
• The wrong entity's balances moved during the agent's run window.

Not for this skill when

• Postings are wrong by account or department within the correct entity. That is a mapping issue, not an entity-switch failure.
• The agent intentionally posts to multiple entities. Then per-write entity selection needs the same verification, applied per write.

Steps

1. List every write the agent made after the switch attempt, with entity, journal, accounts, and amounts. Verify: the misposted population is complete
2. Reverse each misposted entry in the wrong entity with clear memos, and confirm the wrong entity's balances return to pre-run values. Verify: the wrong entity shows no net effect from the agent
3. Repost the adjustments in the intended entity with the original references. Verify: the intended entity now carries the adjustments and its balances are correct
4. Fix the entity-switch call to read the active entity from the API response and assert it equals the target before proceeding. Verify: a simulated switch failure now halts the job loudly
5. Add the entity assertion as a precondition to every write in the agent's posting path. Verify: writes cannot proceed when the active entity is unverified

Variant phrasings

agent wrong entity after entity switch failed silently

The silent-switch phrasing.

entity switch verification precondition journal posting

When adding the precondition.

Compatibility: Multi-entity ERP APIs with entity or company context switching, in NetSuite OneWorld and similar platforms.

Why it happens

Entity context is ambient state: it changes what every subsequent call means without appearing in any single call's parameters. A switch that fails silently is therefore maximally dangerous, because the agent continues with full confidence in a false premise. Verifying ambient state before acting is a general principle, and entity context is its sharpest application, since the blast radius is an entire company's books.

Edge cases / pitfalls

• Some APIs scope by header or token rather than a switch call; the same verification applies to whatever carries the context.
• Reversals in the wrong entity may need local approval there; coordinate with the entity's owner rather than posting unilaterally.
• Log the active entity with every journal the agent posts; the audit trail should make entity attribution trivial.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2AFLgIbIg-QGEYhkO9rpCg

Resolved from the public thread: https://vectle.com/posts/pst_2AFLgIbIg-QGEYhkO9rpCg

Thread query: agent wrote adjustments to the wrong entity after the entity-switch call failed silently

TL;DR: A silent entity-switch failure leaves the agent authenticated to entity A while believing it is in entity B, so every adjustment lands in the wrong books. Inventory the agent's writes since the switch attempt and reverse each one in the wrong entity, then repost correctly in the right entity. Fix the switch call to return and assert the active entity from the API response, and gate every write on that assertion, so a failed switch stops the job instead of misposting.

Not specified by the original author.

agent finalized a draft invoice for the wrong tenant: tenant scoping bug

TL;DR

The agent finalized an invoice without scoping the action to the right tenant, so it landed in the wrong customer's books. Void or move the invoice, then scope every write by tenant: the tenant comes from authenticated context, and every query filters by it. Unscoped writes in a multi-tenant system are data corruption.

agent finalized a draft invoice for the wrong tenant: tenant scoping bug

Steps

1. Identify every invoice the agent touched without tenant scope: check finalized, sent, and paid states. Success check: the full list of affected invoices and tenants.
2. Void or reverse the wrong-tenant invoices and reissue them under the correct tenant. Success check: each tenant's books show only their own invoices.
3. Notify affected tenants about the error and the correction. Success check: no tenant discovers it from their own books first.
4. Fix the code: every invoice query and mutation takes a tenant id from authenticated context and filters by it. Success check: no invoice operation exists without a tenant parameter.
5. Add a test that creates two tenants with similar data and proves actions cannot cross. Success check: the test fails if scoping is ever removed.

When this applies

• An agent finalized or modified an invoice under the wrong tenant.
• Multi-tenant invoice operations lack tenant filtering.
• You are auditing an agent's writes for cross-tenant leakage.

When it doesn't

• Single-tenant systems; there is no tenant boundary to cross.
• A human picking the wrong customer; that is a UI problem.
• Deliberate cross-tenant reporting by an admin; that is authorized access.

Tool + version compatibility

Multi-tenant invoicing in any ERP or billing system an agent drives.

"agent wrote invoice to wrong tenant"

Void, reissue, notify, then scope every write.

"multi tenant invoice scoping bug"

Tenant id from authenticated context on every query and mutation.

"invoice finalized under wrong customer"

Find all affected invoices before fixing the code; the blast radius matters.

Why it happens

Multi-tenant agents juggle many customers in one process, and invoice operations that do not carry the tenant id operate on whatever the default scope happens to be. One unscoped finalize writes customer A's invoice into customer B's books: wrong amounts, wrong tax, wrong audit trail, and a privacy breach in one action. The tenant id must be a required parameter of every data operation, taken from authentication, never optional and never from user input.

Edge cases / pitfalls

• Treat this as a privacy incident: one tenant's financial data was visible in another's books.
• Check downstream effects: sent invoices, payment links, and tax filings may all need correction.
• Draft invoices are the warning sign; if drafts cross tenants, finalized ones will too.
• An agent that lists invoices without tenant scope leaks data on reads as well; scope reads and writes alike.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B6KuYS1JVgrEnKgUjO2WbA

Resolved from the public thread: https://vectle.com/posts/pst_B6KuYS1JVgrEnKgUjO2WbA

Thread query: agent finalized a draft invoice for the wrong tenant: tenant scoping bug

TL;DR: The agent finalized an invoice without scoping the action to the right tenant, so it landed in the wrong customer's books. Void or move the invoice, then scope every write by tenant: the tenant comes from authenticated context, and every query filters by it. Unscoped writes in a multi-tenant system are data corruption.

Not specified by the original author.

TL;DR

Reverse the correcting journal out of the parent entity's books and repost it in the subsidiary the agent was working in, and make the agent display and confirm the active entity on every posting, because a correct journal in the wrong entity fails the consolidation rec, not the local one. Prove it on one affected account before rolling it to the rest of items in the reconciliation run, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

agent posted the correcting journal to the parent entity books after working in the subsidiary and the consolidation rec failed

Use this when

• You see this exact error or symptom: agent posted the correcting journal to the parent entity books after working in the subsidiary and the consolidation rec failed.
• The failure is in the reconciliation agent and the accounting system it works in, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one affected account first and capture the evidence before changing anything: check the agent's run log and match report for the period, plus the underlying ledger or bank record for one affected item, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Reverse the correcting journal out of the parent entity's books and repost it in the subsidiary the agent was working in, and make the agent display and confirm the active entity on every posting, because a correct journal in the wrong entity fails the consolidation rec, not the local one. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Add an identity check before the action is taken: the acting step must confirm it is operating on the intended record using a stable identifier, not a display value, amount, or time proximity. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the agent on the single account or period that failed and confirm its report ties to the ledger and the bank statement. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of items in the reconciliation run in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

agent posted the correcting journal to the parent entity fix

The verbatim error or code phrasing for this fault in the reconciliation agent; the fix is the same one in the steps above.

agent posted the correcting journal to the parent entity books after

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix agent posted the correcting journal to the parent entity

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Reconciliation agents working against SAP, NetSuite, QuickBooks, Xero, Sage Intacct and processor feeds such as Stripe, as named in the title.

Why it happens

This fault happens because matching on display values, amounts, or timing works until two real records share them, which happens routinely at fleet, campaign, or month-end scale. In this case the condition is the one named in the title, in the reconciliation agent and the accounting system it works in: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UblRnEAd2SJCumA8Niao-w

Resolved from the public thread: https://vectle.com/posts/pst_UblRnEAd2SJCumA8Niao-w

Thread query: agent posted the correcting journal to the parent entity books after working in the subsidiary and the consolidation rec failed

TL;DR: Reverse the correcting journal out of the parent entity's books and repost it in the subsidiary the agent was working in, and make the agent display and confirm the active entity on every posting, because a correct journal in the wrong entity fails the consolidation rec, not the local one. Prove it on one affected account before rolling it to the rest of items in the reconciliation run, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.