Do you match counterparties by name?

No. Attribution runs on identifiers: an IBAN, a supplier or customer code, an account already registered against a party, or the document a movement settles. Names are held so that a person can search, and a name resembling another name never causes two records to be treated as one.

Two of our systems created the same supplier twice. Can we merge them?

Yes. A merge moves the identifiers, the registered accounts and every name the losing record arrived under onto the surviving one, and the movements already attributed follow it. Both records’ names stay on file, because a name that appeared in a source system is a fact about that system.

Who settles a movement nobody could decide?

Your team, from the counterparties screen, choosing between the companies the evidence already named. The decision is stored with who made it and when, it outranks the engine’s verdict from that point on, and it is reproduced exactly the next time the movement is resolved.

Where do our supplier and customer records come from?

From your own masters — SAP, Oracle, Business Central, or whatever the group runs — including the codes, the tax ids and the bank accounts registered against each one. Tresora reads them as they are and asks nobody to key them a second time.

Does an attribution survive a re-run?

Yes, and it is the test worth running. Each verdict is written when the decision is made rather than computed when a screen opens, so resolving the same movement against the same records returns the same answer — and where a person settled it, theirs.

Who is on the other side

The same company arrives under four names. One counterparty comes out.

Your supplier master calls it one thing, your customer master another, the payment file a third and the bank line a fourth. Tresora decides those are one party from the identifiers they carry — never from how alike the names look — and keeps the record that decided it.

Request a demo

One supplier, as four systems hold it

Supplier master
KELBRAND SUMINISTROS SA
Supplier code4400871
Customer master
KELBRAND SUMINISTROS S.A.
Customer code1200458
Payment instruction
Kelbrand Suministros, S.A.
IBANES•• •••• •••• 8317
Bank statement line
KELBRAND SUM SA //FRA 26-0412
No identifier

The three identifiers are what tie these records to one party. The fourth line is a bank’s own text, and it ties nothing to anything.

Booked in 6 entities of the group

Identity, not names

How do you know two records are the same counterparty?

Four lanes, each reading a different record, in a fixed order. A lane either names a party and shows what named it, or it finds nothing — and finding nothing is a result the verdict keeps.

01The movement is between two entities of your own group.: The ledger says which entity of the group an entry faces, and the code is read straight out of the account it was posted to. That check runs first: an intercompany transfer attributed to an outside party is a payable that does not exist. Intercompany entity
02The movement carries an identifier the party is already known by.: An IBAN, a BIC and account number, a supplier or customer code, a tax id. Each one is held against the party it belongs to, so the match is an equality on a value your own systems assigned — not a comparison between two strings that look alike. Identifier on the movement
03The account the money moved to is one you already hold for a party.: Accounts are registered against counterparties as payments are confirmed, so a second payment to the same account is recognized by the account rather than by the beneficiary line. An account nobody has paid before is marked as exactly that, and it never inherits whoever was paid last. Account already on file
04The movement settles something that already has an owner.: A bank line that clears an invoice, or completes an instruction the group sent, takes its party from the document it settles. Where it settles two documents belonging to two different companies, that is a conflict rather than a tie to break. What the movement settles

A name is how a person finds a counterparty. It is never how the system decides one. Spellings drift, banks abbreviate, and one company gets keyed twice by two people in two countries, while an identifier is assigned once and travels with the record carrying it.

The decision, kept

Which counterparty is this movement for, and what decided it?

Every attribution is written at the moment it is made: the lane that won, the record that proved it, and what each of the other lanes returned. Nothing gets argued again later from a screen.

Resolver Diagnostics · one movement

Movement

EUR -84,260.00

PMT 20260814-0412 · Aug 14

Booked as

KELBRAND SUM SA //FRA 26-0412

What each lane returned

Intercompany entity: Nothing found
Identifier on the movement: Kelbrand SuministrosES•• •••• •••• 8317
Account already on file: Kelbrand SuministrosCP-4400871
What the movement settles: Kelbrand SuministrosPI 20260814-0412

Verdict

Kelbrand SuministrosAttributed

Decided by · Identifier on the movement

Every lane runs, including the ones that find nothing. A lane with no answer is part of the record — it is how you know the question was asked at all.

Three records named the same party, and the verdict says which of them decided it. Nothing here was ranked by a threshold somebody tuned, so resolving the movement again against the same records returns the same answer.

There is no percentage to tune here. A lane found its record or it did not, and two lanes naming two companies is a conflict rather than a closer call.

When it will not guess

What happens when the evidence names two parties?

Nothing is attributed. A wrong counterparty is worse than an empty one: it lands in somebody’s payables, on a supplier statement and in a report that gets sent upward. The movement is left unresolved, with both companies the evidence named sitting on it.

Resolver Diagnostics · contested

Movement

EUR +12,940.00

RCPT 20260814-0517 · Aug 14

Booked as

TRANSF SEPA //FRA 26-0517

What the evidence names

Ardenta Retail1400071842: What the movement settles
Ardenta Servicios1400071903: What the movement settles

Found nothing

Intercompany entity · Identifier on the movement · Account already on file

Verdict

UnresolvedThe evidence names two companies

The last lane found two open documents, one under each company, and there is no lane below it to rank them with. That is the whole reason this row has no answer.

A person settles it, and only between the companies the evidence named.: Both candidates are already on the record, so the choice is between them. Nobody types in a third company the source records never supported: an attribution that traces back to no document is exactly the figure an auditor stops on.
Belonging to nobody in particular is also an answer.: A receipt that genuinely covers two companies is not a call anyone can make cleanly. It gets recorded as that, once, and the queue stops asking.
Settling it does not rewrite what the records said.: Choosing a winner never turns two companies into one. The verdict goes on saying the evidence named two, the person’s decision sits beside it with their name and the moment they made it, and both survive every later re-run.

Who decides

Tresora reads the records, names the companies they support and stops there. Which of them owns the movement is your team’s call, made on the evidence and stored with it.

What it reads

What can create a counterparty, and what never can?

Structured records create counterparties. Free text does not, in either direction: a bank’s own detail line is read, kept beside the movement it came on, and never turned into a party on your book.

Creates a counterparty

Your supplier master — the code, the name it holds, the accounts registered against it
Your customer master, read the same way
The beneficiary of a payment instruction, once that payment is confirmed
An entity of your own group, decoded from the ledger account an entry faces
A person, deliberately, on the counterparties screen

Never creates one

A name in a bank’s free text, however unmistakable it looks
A name that resembles one already on the book
A beneficiary on an instruction that was never sent
Anything the engine inferred rather than read

One group’s book

Counterparties on the book: 2,418; Suppliers, customers, banks and the group’s own entities.
Identifiers held against them: 5,106; Supplier and customer codes, IBANs, tax ids, creditor ids.
Names they arrive under: 3,270; Each party’s canonical name, plus every other spelling seen.
Movements waiting for a person: 9; The evidence named more than one company on each.

None of this is a cleanup project you finish before you start. The book is built out of the records you already keep, and a company you have never traded with does not appear on it until one of those records says so.

What comes back

What do you get back, and who actually uses it?

One record per company and one decision per movement, both readable long after the day they were made.

One party, and every name it uses: The canonical name the source system owns, every spelling the party has arrived under, and the identifiers that tie them together. A name a person added is marked as theirs and can be withdrawn without touching what your ERP holds.
Every attribution, with the lane that made it: The winning lane, the record it read, what the other lanes returned, and the companies the evidence named. Open any movement and the answer to “why this counterparty” is already sitting on it.
One company’s position across the whole group: What each of your entities owes it and what it owes each of them, in the currency each side books in — so a supplier you also sell to stops being two unrelated conversations in two departments.
A queue that is short by construction: Only the movements where the evidence named more than one company, each with those companies and the records that named them. Everything the evidence settled on its own never reaches it.

Who reads it

Where it is used

Questions

What buyers ask about counterparty data

01Do you match counterparties by name?: No. Attribution runs on identifiers: an IBAN, a supplier or customer code, an account already registered against a party, or the document a movement settles. Names are held so that a person can search, and a name resembling another name never causes two records to be treated as one.
02Two of our systems created the same supplier twice. Can we merge them?: Yes. A merge moves the identifiers, the registered accounts and every name the losing record arrived under onto the surviving one, and the movements already attributed follow it. Both records’ names stay on file, because a name that appeared in a source system is a fact about that system.
03Who settles a movement nobody could decide?: Your team, from the counterparties screen, choosing between the companies the evidence already named. The decision is stored with who made it and when, it outranks the engine’s verdict from that point on, and it is reproduced exactly the next time the movement is resolved.
04Where do our supplier and customer records come from?: From your own masters — SAP, Oracle, Business Central, or whatever the group runs — including the codes, the tax ids and the bank accounts registered against each one. Tresora reads them as they are and asks nobody to key them a second time.
05Does an attribution survive a re-run?: Yes, and it is the test worth running. Each verdict is written when the decision is made rather than computed when a screen opens, so resolving the same movement against the same records returns the same answer — and where a person settled it, theirs.

Bring your two masters and one month of statements.

We read your supplier master, your customer master and the movements against them, then show you which records are one company, which are two, and which ones the evidence cannot decide.

Request a demo See the whole product

Every attribution you see arrives with the record that produced it, and the list is yours to keep.