agent applied a customer payment to the parent company account instead of the subsidiary that issued the invoice and...

Not specified by the original author.

TL;DR

The money was applied to a real customer - the wrong one. Parent and subsidiary share a name root and often a bank account, so the agent matched the payment to the parent's ledger while the invoice, and the receivable, live in the subsidiary. Unapply the payment from the parent, which also unwinds the false intercompany position it created, and apply it in the subsidiary against the actual invoice, letting the proper intercompany entries arise from the real bank location of the cash: if the cash physically sits in the parent's bank, the subsidiary's receipt is settled through intercompany, recorded as such on both sides in the same run. Then constrain the agent: payment application must verify that the invoice's entity equals the ledger it is posting to, and any cross-entity temptation routes to a human with the intercompany treatment spelled out, because cross-entity cash is a designed process, not a matching shortcut.

agent applied a customer payment to the parent company account instead of the subsidiary that issued the invoice and the intercompany rec broke

Use this when

• A customer payment was applied in the parent entity while the invoice was issued by a subsidiary, or the reverse.
• The intercompany reconciliation between the two entities broke by the payment amount in the same period.
• Group customers trade with several group entities under similar names.

Not for this skill when

• A central treasury agreement says the parent collects for subsidiaries by design. Then the original application may be right and the intercompany design is the question.
• The payment belongs to a genuinely different customer with a similar name outside the group. That is a customer identity error, not an entity error.

Steps

1. Confirm the facts: the invoice's issuing entity, the bank account that received the cash, and where the agent applied the payment. Verify: all three locations are established from documents, not assumptions
2. Unapply the payment in the parent and reverse the intercompany entries the false application generated. Verify: the parent's AR and the intercompany balances return to their pre-application state
3. Apply the payment in the subsidiary against the correct invoice, recording the intercompany settlement for the cash location if the bank account was the parent's. Verify: the invoice closes in the subsidiary and both entities carry mirror intercompany entries
4. Run the intercompany reconciliation for the pair and confirm the payment no longer appears as a difference. Verify: the pair reconciles with the payment correctly placed
5. Add the entity check to the agent's application rules: invoice entity must equal posting entity, cross-entity cases go to review with a proposed intercompany treatment. Verify: a test cross-entity payment is routed to review instead of being applied

Variant phrasings

agent applied customer payment parent instead of subsidiary intercompany rec broke

The wrong-entity application symptom.

multi entity cash application entity verification invoice entity check agent

The verification-rule phrasing.

payment received parent bank for subsidiary invoice intercompany settlement fix

The legitimate cross-entity design search.

Compatibility: Multi-entity AR in NetSuite OneWorld, SAP, Oracle, Dynamics and Workday, with agent or RPA cash application across group entities.

Why it happens

Entity is the dimension agents are most likely to treat as a label rather than a legal boundary, because names, customers and bank accounts overlap heavily inside groups. A payment matched on customer and amount alone will land in whichever ledger the agent searched first. But entities are separate legal persons: the wrong-entity application simultaneously overstates one company's collections, leaves another's receivable open, and fabricates an intercompany difference that two finance teams then chase from opposite ends, each convinced their own books are right.

Edge cases / pitfalls

• Centralised bank accounts are legitimate when designed: document the design so agents and auditors can distinguish design from error at a glance.
• Customer remittances often name the group, not the entity; the invoice number, not the payer name, is the reliable entity signal.
• Review the agent's other applications for the same customer group; entity confusion clusters around shared-name customers.

Provenance

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

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

Thread query: agent applied a customer payment to the parent company account instead of the subsidiary that issued the invoice and the intercompany rec broke

TL;DR: The money was applied to a real customer - the wrong one. Parent and subsidiary share a name root and often a bank account, so the agent matched the payment to the parent's ledger while the invoice, and the receivable, live in the subsidiary. Unapply the payment from the parent, which also unwinds the false intercompany position it created, and apply it in the subsidiary against the actual invoice, letting the proper intercompany entries arise from the real bank location of the cash: if the cash physically sits in the parent's bank, the subsidiary's receipt is settled through intercompany, rec