How to Achieve Close to 100% Automated Payment Matching in Factoring Operations
- Published
- 6 min reading
Anyone who has managed settlement operations in a factoring company knows what Monday morning looks like.
A weekend's worth of incoming bank transfers, each with a different format, a different level of detail in the title field, some with sender names that don't quite match any contract in the system, a few with amounts that are off by a few cents. Your team sits down, opens the reconciliation queue, and starts working through it manually. By the time they're done, a meaningful chunk of the day is gone.
This is the reality of payment matching at volume. And it's one of the more stubborn operational problems in factoring, not dramatic enough to trigger a transformation project, but expensive enough to consume thousands of hours of team capacity every year quietly.

Why Manual Matching Is Hard to Eliminate Entirely
The instinct is to assume that payment matching is a solved problem. After all, the system knows what's owed, and the bank knows what arrived. Surely they can just be compared automatically.
In practice, it's more complicated.
The system needs to identify two things for every incoming transfer: who sent it, and which contract it relates to. Both answers depend almost entirely on the quality of the data in the transfer title, and let’s just say that quality varies enormously by sender.
Large corporate clients tend to follow a consistent format. Their payments arrive with structured references, contract numbers, and sender details that match cleanly against system records. Automated matching works well here, with matching rates approaching 100%.
Smaller clients are a different story. A transfer might arrive with a handwritten title, an abbreviated company name, a partial invoice number, or nothing useful beyond the amount. The same client might format their transfer differently every month. One month it's a contract reference; the next it's just their trading name and a round number.
That inconsistency is the core of the problem.

The Algorithms, in Order of Effectiveness
The simplest automatic matching approach is FIFO, first in, first out. When a payment arrives from a recognized sender, it's applied against the oldest outstanding obligation on that contract. It works well enough when clients pay one invoice at a time, in order, without partial payments or consolidations.
But that describes a minority of real-world transactions.
More sophisticated matching algorithms work from the transfer title and the amount, looking for exact references to contract numbers, invoice identifiers, or client codes. This works reliably when senders are precise. The limitation is that they often aren't. A Polish client who owes on contract "FKT/2026/00123" might put "FKT 123" in the title, or "faktura 123," or just "123." An exact-match algorithm misses all of those.
The next step is fuzzy matching, algorithms that look for partial character matches rather than exact matches. The logic acknowledges that senders make mistakes, abbreviate, or simply don't know what format the system expects. If an incoming transfer title contains a recognizable fragment of a contract reference, even with typos or missing characters, the algorithm can still flag it as a probable match.
This is where matching rates improve meaningfully. Partial-string matching catches a significant portion of the cases that exact matching misses, because most sender errors are small, such as a missing digit, a transposed character, or a different separator.
Where Comarch's Factoring System Currently Stands
At Comarch, automated matching effectiveness on the factoring platform currently ranges from 70% to 100%, depending on the quality of transfer descriptions from clients' counterparties. For portfolios where clients tend to use structured, consistent payment references, the system handles nearly everything automatically. For portfolios with lower-quality transfer data, the rate sits closer to 70%, with the remainder queued for manual review.
That 0–30% manual residual isn't a system failure. It's an honest reflection that some transfers simply don't carry enough information to match automatically with confidence. Applying a low-confidence match automatically creates a different problem: incorrectly settled payments that require correction later, which is more expensive than the original manual work.
So the current design is deliberate. High-confidence matches happen automatically. Ambiguous cases go to an operator queue.

Where AI Fits, and Where It Doesn't (Yet)
The next phase in Comarch's factoring platform development introduces AI-assisted matching for the ambiguous cases.
The model analyzes the full context of an uncertain transfer, sender history, payment patterns, amount relationships, and partial title fragments, and generates a suggested settlement for the operator to review. Rather than the operator starting from scratch and searching manually, they're presented with a ranked recommendation and can approve, adjust, or override it.
This is a meaningful productivity gain for settlement teams. The system does the hard cognitive work of identifying the likely match. The human confirms or corrects.
The key design decision here is that the final call stays with the operator. AI-suggested matching is presented as a recommendation rather than an automatic action. That distinction matters in factoring, where a misapplied payment can trigger incorrect interest calculations, client reporting errors, and downstream compliance issues. The cost of a confident wrong answer is higher than the cost of a cautious one.
Trust in AI recommendations will grow as the model accumulates a track record. For now, the architecture reflects a reasonable position: use AI to reduce the cognitive load of manual matching, while keeping a human in the decision loop for anything that isn't clear-cut.

The Operational Case for Getting This Right
At scale, the difference between 70% and 95% automated matching isn't just a productivity metric. It's a capacity question.
A factoring operation processing several thousand transfers monthly, with a 30% manual residual, is dedicating significant analyst time to a task that doesn't require judgment, just pattern recognition. That's exactly the category of work that automation should be handling, freeing the settlement team for exception management, client queries, and the genuinely complex cases that require human attention.
Comarch's factoring platform is built to push automated matching as high as the data quality allows, and to continue improving that ceiling through AI-assisted recommendations that work with operators rather than around them.
For factoring companies looking to reduce manual settlement overhead without introducing the risk of unchecked automated errors, that combination of high-confidence automation and human-reviewed AI suggestions is probably the most realistic path to close to 100%.
Not across all portfolios, and not all at once. But consistently, and in the right direction.
Want to see how the matching logic works in practice? Talk to Comarch's team to review your current settlement volumes and where automation can make the most immediate impact.
