Correct counterparty assignments

Reassign transactions to the right counterparty, handle duplicate counterparties, and verify the result.

A counterparty assignment links an individual transaction to a customer, vendor, employee, bank, or other business party. It is separate from account mappings and dimension mappings.

Use the transaction view for row-level corrections. Use a write-enabled MCP connection or contact Control support when you need to review a larger batch, update shared counterparty details, or merge duplicates.

Choose the right correction

What is wrong?	Correct action
Specific transactions show the wrong counterparty	Reassign those transaction rows.
One organization appears as several duplicate counterparties	Review and merge the duplicates, keeping one primary counterparty.
The transactions are linked correctly, but the shared name or role is wrong	Update the counterparty details instead of reassigning every transaction.
The source description, account, date, or amount is wrong	Correct the source data or account mapping. A counterparty change will not fix it.

Correct transactions manually

1. Open .
2. Select the affected entity and period. Add account filters when you know which statement rows are affected.
3. Choose All so the grid shows individual transaction rows.
4. Filter the Counterparty, account, or description columns until only the relevant rows remain.
5. Hover over or focus the Counterparty cell and select the pencil icon.
6. Select an existing counterparty, choose None to remove an incorrect assignment, or search for a new name and create it when the counterparty does not exist yet.
7. Repeat for each affected row, then clear the filters and verify the result.

Creating a counterparty from one row creates the shared counterparty and assigns that row. It does not automatically reassign other transactions with a similar description or source name.

For an urgent revenue correction, filter to the affected entity, period, and revenue accounts first. Correct the counterparty cells in All, then group the same scope by counterparty. The revenue total should remain unchanged; only its counterparty distribution should move.

If the edit control is missing

The counterparty column appears only when the workspace has AI-reviewed transaction data. The pencil icon also requires write permission and an individual transaction row.

Confirm that:

• you selected All, not a grouped or pivot row;
• your user role can edit financial data; and
• the workspace has completed AI transaction review for the affected data.

If the counterparty column is still unavailable, contact Control support with the entity, period, affected account, and redacted transaction identifiers.

Correct a reviewed batch with Claude or another AI client

A manually configured Control MCP connection can expose write tools when the session and your Control role allow them. The marketplace connector is read-only and cannot change transactions, mappings, or counterparties.

Use a preview-first prompt such as:

In Example Corp, review January 2026 transactions in the revenue accounts. Find rows currently assigned to Example Customer A that should belong to Example Customer B. Return the exact source-system transactionId values, current counterparty, proposed counterparty, account, date, and value. Do not make changes yet.

Review the complete proposal. Before any write, record the approver, reviewed scope, selected source-system transactionId values, and decision in a durable audit trail outside MCP. If it is correct, approve only those recorded transactions and ask the client to apply the assignments through Control MCP, then re-read the changed rows. Do not approve a write based only on a counterparty name or a grouped total. MCP operational logs are not a durable user-visible audit record; see Connect external tools through MCP.

If the client does not expose control_api_request, reconnect the manually configured MCP server with the intended write access or make the corrections in Control. See Connect an AI client with MCP.

Handle duplicate counterparties

Do not rename one duplicate to match another. Renaming changes shared display details but does not combine transaction assignments.

Before merging duplicates:

1. List every possible duplicate and its transaction count.
2. Inspect sample transactions for each candidate.
3. Choose the primary counterparty to keep.
4. Confirm that every other selected counterparty represents the same real-world party.
5. Record the approver, reviewed scope, primary and merged counterparty IDs, and decision in a durable audit trail outside MCP.
6. Approve the merge only after reviewing and recording its full scope.

A merge transfers all transaction classifications to the primary counterparty and deletes the merged counterparties. It cannot be undone. Use a write-enabled MCP connection or contact Control support for this workflow.

Verify the correction

After a manual or MCP-assisted change:

1. Reopen or refresh the same transaction scope.
2. Group by counterparty and confirm that the corrected rows moved to the intended party.
3. Confirm that the transaction count and total value still reconcile to the original account and period.
4. Return to the statement drilldown when the investigation started from a report.

A counterparty reassignment changes counterparty reporting. It does not change the transaction amount, account mapping, dimension mapping, or source-system record.

Related content

• Investigate transactions
• Connect an AI client with MCP
• Account mappings
• Keep transaction data current