How to Match a Wire With No Remittance Information

Match a wire with no remittance by working down an identification hierarchy rather than asking the customer first: exact and combination amount matching, payer name normalisation, historical payment pattern, then currency and originating bank, and only after those fail, a targeted question to the customer. Monk is an AI-native invoice-to-cash platform that runs invoicing, cash application, collections and disputes as one system, so the bank credit, the candidate invoices and the payer's history sit in one place while the identification is made. A bare wire carries more than it appears to. Amount, value date, ordering customer name, originating BIC and any free text are usually enough to identify the payer without contacting anyone.

The situation looks like this. On 3 September 2026 a credit of £62,450.00 appears on your statement. The ordering customer field reads GLBL TRDNG SVCS LTD, the originating BIC is a UK clearing bank, and the reference says INV PAYMENT AUG. No customer in your ledger is called Global Trading Services, and nothing on the payment names an invoice. The money is real, the customer is not obvious, and until you resolve it somebody is being chased for an invoice they have already paid.

What does the identification hierarchy look like, in order?

Work from the cheapest signal to the most expensive, and stop as soon as two independent signals agree.

Start with the amount, because it costs nothing to test. Search open invoices for an exact match, then for two and three invoice combinations. No single open invoice equals £62,450.00, but three two-invoice combinations across the ledger do, which narrows the field to three customers.

Move to the payer name, normalised. Uppercase it, strip punctuation and legal suffixes, expand the common abbreviations, and compare against both the customer name and the registered company name. GLBL TRDNG SVCS LTD normalises to GLOBAL TRADING SERVICES, the registered name of the company your ledger holds as GTS Distribution Ltd. That is one of the three candidates, and two signals now agree.

Confirm with history. The originating account has paid you three times in the past year, and each of those receipts went to GTS Distribution. Check the arithmetic: INV-20918 at £41,200.00 plus INV-21044 at £21,250.00 is £62,450.00, and both fell due in August, which fits the payment reference. Currency and originating bank are the tie breakers when earlier steps leave two candidates standing, and asking the customer comes only when everything above has failed.

Why does the payer name almost never match your customer record?

Because payment rails truncate and abbreviate names, and because the entity that pays is often not the entity you invoiced.

The mechanics do most of the damage. A SWIFT MT103 carries the ordering customer in field 50K across four lines of 35 characters, and treasury systems abbreviate to fit. An ACH company name field is sixteen characters, so Northumberland Water Services Ltd arrives as NORTHUMBERLAND W. BACS and Faster Payments originator fields are similarly short. A name reaching your statement has passed through the payer's ERP, their bank's formatting rules and your bank's truncation, and each stage removes characters.

The second cause is structural. Companies trade under one name and pay under another, group treasury pays for subsidiaries, an acquired business keeps its old registered name in the banking records for years, and factored receivables arrive from a funder. Payment service providers and virtual account platforms add a further layer, because the ordering customer may be the platform rather than the buyer.

A normalisation routine handles most of this. Uppercase, strip punctuation and the words THE and C/O, remove legal suffixes such as LTD, PLC, INC, LLC, GMBH, BV and SA, expand a dictionary covering SVCS, TRDNG, INTL, MFG, GRP and DIST, then fuzzy match against customer name, registered name, previous names and trading names. The alias list per customer is the part that pays for itself, because a payer identified once should never need identifying again.

How much can historical payment behaviour tell you?

More than the payment itself, because the same customer tends to pay the same way from the same account every month.

Four attributes are worth storing against every payer record: the originating account or its hashed identifier, the originating BIC, the usual day of month and the usual charging basis on cross border payments. Once a bank account is linked to a customer, any future credit from it is identified before anyone looks. Most teams never build this, because the information is discarded once the first payment is applied.

Behaviour also narrows the invoice selection. A payer who settles on the last working day of the month is paying the batch approved in the previous cycle. A payer who has never split an invoice will not have split one now. A payer who always deducts a small correspondent charge has deducted it again, which explains an amount of £62,427.42 rather than £62,450.00 and stops you hunting for a combination that does not exist.

Round numbers deserve suspicion. A credit for exactly £50,000.00 from a customer whose invoices are never round is usually a payment on account or a customer paying what their cash position allowed. Those go to on-account with a note rather than being forced onto invoices.

Why is asking the customer the slowest option rather than the first?

Because the question travels through the slowest part of the chain and often reaches somebody who did not send the payment.

To ask, you first need to know who to ask, which is the problem you are trying to solve. If the payer name is unrecognisable you are guessing at a recipient, and a guess sent to the wrong AP mailbox produces no reply and no signal. Even with the right company, the person who released the payment usually sits in treasury or in a shared service centre, while your contact sits in accounts payable, so your question gets forwarded at least once.

Then there is the round trip. A remittance request takes several working days to answer, and the answer often arrives as a screenshot of a payment screen rather than a remittance advice, which starts a second exchange. Meanwhile the cash is unapplied, the invoices are open, and the collections cycle keeps running against a customer who has paid.

Asking is still the right final step, and there is a good and a bad way to do it. The bad version asks the customer to send a remittance for a payment you cannot describe. The good version names the amount, the value date, the ordering account name as it appeared and the invoices you believe it covers, and asks them to confirm. Confirmation takes a minute and research takes a week.

What does a good unapplied cash policy look like?

It sets a time limit, an owner and an escalation path for every receipt, and it treats the unapplied balance as a queue to be cleared rather than an account to be carried.

The core of the policy is a service level. Identify and apply within one working day where the payer is known, within five where it is not, and escalate to the account owner at ten. Tier by value, so a £200,000.00 unidentified receipt gets attention that day and a £45.00 one does not consume an afternoon. Give every unapplied item a named owner when it is created, because an unowned item is one nobody clears.

Structure matters as much as speed. Keep unidentified cash in suspense and identified but unallocated cash as an on-account balance, since those are different problems with different owners. Age both the way you age receivables, review them at the same monthly meeting, and reconcile suspense to the bank every month. Set a rule that the period does not close with suspense above an agreed threshold, which is the constraint that makes the rest of the policy real.

Two further rules save trouble later. Every application and reversal needs an audit trail showing who did it and why, because reapplications are where errors compound quietly. And define what happens to an overpayment nobody claims, including when it is refunded, so old credits do not accumulate indefinitely.

What does unapplied cash cost you in collections conversations?

It costs you the credibility that makes every later conversation work, and the damage compounds across the account.

Start with the immediate error. A customer who paid £62,450.00 on 3 September receives a chase for those two invoices on 10 September. They reply with their payment confirmation, and from then on your statements are treated as unreliable. The next chase, for an invoice that is overdue, gets checked against their records before anyone acts, adding a week to every collection on that account.

The knock on effects reach past the AR team. Credit control may block new orders because the exposure looks higher than it is, and sales then escalates a problem that does not exist. The cash forecast understates collections, so treasury plans around money it already holds. And a customer chased in error will often look harder for a reason to withhold the next payment.

There is a quieter cost inside the team. Collectors work from the aging report, and every wrong line spends a contact that could have gone to a real debt. Once collectors start verifying each line by hand, the productivity the system was meant to create is gone.

How does Monk handle this?

Monk identifies the payer before it identifies the invoice, and it keeps what it learns so the same payer is recognised next time.

Monk's AI cash application matches around 80% of incoming payments automatically, rising to 95% once suggested matching rules are in place. For bare wires those rules are the payer level ones: this bank account belongs to this customer, this abbreviated name maps to this registered entity, this payer always deducts a correspondent charge, this payer pays on the last working day. Each rule is confirmed by a person once and then applied on its own.

Monk reads bank data and remittance artefacts in the formats they arrive in, including BAI2 and EDI 823 lockbox files, EDI 820 remittances, ACH addenda records, PDF remittance advices and hand exported CSVs, and pairs a remittance to a receipt when the two arrive days apart from different senders. Where a wire arrives with nothing attached, the exception carries the candidate customers, the candidate invoice combinations and the payment history behind each, so the decision takes a minute. Monk's measurement is that 39% of cash flow slowdown comes from edge cases.

Because collections and cash application live in the same system, an unapplied receipt is visible to collections before a chase goes out, which prevents the credibility problem described above. Monk syncs to QuickBooks, NetSuite, Salesforce, HubSpot and Stripe. Teams running Monk report 26 hours a month saved on receivables work and a 40% average reduction in DSO, and Monk is SOC 2 Type II compliant.

Where should you start?

Age your unapplied and suspense balance this week and count the items rather than the value.

Value tells you the exposure and item count tells you the workload. Most teams find a few large receipts everybody knows about and a long tail of small ones nobody owns. Sort by age, and give anything older than thirty days a name and a date today. Then count how many items come from payers you have seen before, because a payer alias list would have caught those.

Next, build the alias list. Take your top fifty customers and record the bank account or originating BIC they pay from and the exact name string that appears on your statement, plus the registered company name and any trading names. That is an hour of work against past receipts and it removes a recurring category of exception permanently.

Finally, write the policy down: the service level, the owner, the escalation point, the suspense threshold at close, and the rule that no chase goes to an account holding unapplied cash. To see payer identification and the exception queue on your own bank feed, book a demo.

Frequently Asked Questions

What is unapplied cash?

Unapplied cash is money you have received but have not matched to an invoice. It splits into two states: cash where the payer is unknown, which belongs in suspense, and cash where the payer is known but the invoices are not, which belongs as an on-account balance. The distinction matters because they have different owners and different resolution paths. Age and review both monthly alongside receivables.

Can I identify a payer from the bank statement alone?

Often, yes. The ordering customer name, the originating BIC or sort code, the value date, the amount and any free text together identify most payers without contacting anyone. The name will be truncated or abbreviated, so normalise it before comparing it to your ledger. Where the bank feed is thin, the fuller payment message, such as an MT103 copy or an ISO 20022 camt.053 file, carries more fields.

How long should I wait before contacting the customer?

Exhaust the amount, name, history and bank corridor checks first, which takes minutes rather than days, then contact the customer the same day if the payment is material. Waiting a week to ask is worse than asking early, and asking before the cheap checks wastes a contact. When you ask, name the amount, the date, the payer name as it appeared and the invoices you believe it covers, and request confirmation rather than research.

Should I post an unidentified receipt to suspense or leave it unposted?

Post it to suspense. Leaving a bank credit unposted breaks the bank reconciliation and hides the item from any review working off the ledger. A suspense posting keeps the cash visible, the bank reconciled, and creates an item that can be aged and owned. Reconcile suspense monthly and keep it small enough that every line can be explained.

What is payer name normalisation?

It is the process of reducing a bank supplied name to a comparable form before matching. Typical steps are uppercasing, stripping punctuation and legal suffixes, removing filler words, expanding abbreviations such as SVCS and TRDNG, then fuzzy matching against customer, registered, previous and trading names. Keep the output as an alias list per customer, so a name identified once is recognised automatically next time.

What should I do with a genuine overpayment?

Hold it as an on-account credit, show it on the customer statement, and agree whether to refund it or apply it to the next invoice. Do not net it silently against unrelated invoices, because that hides the credit and confuses the next reconciliation. Set a policy for how long an unclaimed credit can sit before escalation, and record the decision when it is cleared.

Does chasing a customer who has already paid do real harm?

Yes. An incorrect chase teaches the customer that your statements need checking, which slows every later collection on that account and can trigger defensive disputes on the next invoice. It also wastes a contact, which is limited on any account. The safeguard is to suppress dunning for accounts holding unapplied or on-account cash until the position is resolved.