Cash application is the work of getting each payment onto the right invoice on the right client’s account. For a factor it is harder than it is in accounts receivable, because one debtor payment covers many invoices across several clients, the remittance detail arrives separately from the money, and what you post is what your reserve releases and your dilution number measures.
Four of our own guides lean on this discipline and none of them describes it. The staffing guide calls the back office “invisible when it works and expensive when it doesn’t” and moves on. The funding-stack guide turns it into a pass or fail at the field exam. The onboarding guide tests the first funding by asking whether the advance and reserve posted the way the agreement says. That is the shape of a topic everybody assumes and nobody writes down, so here it is.
Search it and you get software. Either corporate accounts-receivable automation written for a company collecting its own invoices, or factoring platforms explaining why their product solves it. The tooling question is real and it is not this page. This page is how posting works, where it breaks, and what the breaks cost you.
Why a factor’s version is a different job
In ordinary accounts receivable, a misapplied payment is an internal error. The money is in your company’s bank account either way, the customer is one customer, and the fix is a journal entry.
A factor has none of that comfort. One broker’s Thursday wire can cover forty invoices belonging to a dozen different carriers, so applying it wrong does not move money between line items. It moves money between other people’s reserve accounts. Post an invoice to the wrong client and you have credited one carrier with cash that belongs to another, and both of them will eventually notice, at different times, for different reasons.
Three consequences follow, and they are why this desk deserves more attention than it gets. Cash you cannot apply sits unapplied, which means the client whose invoice actually paid does not get their reserve released. Dilution, one of the five numbers in our monthly metrics guide, is only ever as accurate as the codes your posting desk enters. And your aging, the report your lender reads, is only as good as what has been applied against it.
The money and the paperwork do not travel together
Start with the mechanical reason cash application is hard, because most people working the desk have never been told it.
A wire or an ACH credit carries very little room for explanation. In the ACH network, the field that carries remittance detail is the Payment Related Information field in an addenda record, and Nacha’s own developer documentation describes it as “an optional freeform text field that will travel with the payment instruction to the RDFI” occupying positions 04 through 83, which is 80 characters. The same documentation notes that the common corporate formats “only allow for one addenda per record,” while the CTX format built for corporate trade payments “support[s] up to 9,999 addenda records.”
Eighty characters is roughly this sentence. It is not enough to describe forty invoices, and most payers do not use the format that would be. So the detail comes another way: an emailed remittance advice, a spreadsheet attachment, a PDF stub, a broker portal somebody has to log into, or a check stub that arrived with the paper.
Treat that as a real intake problem with a real owner, because it is the root cause of most unapplied cash. The payment and the explanation arrive through different doors, at different times, and sometimes one of them never arrives at all. Know for each significant payer where their remittance detail comes from, who retrieves it, and how often. A payer who only posts remittance detail in a portal, with nobody assigned to log in, is a permanent exception queue you built yourself.
Matching, and the queue where the hard ones go
Most payments match on the first pass, and most shops are fine at the easy half. The discipline is in what happens to the rest.
An exception queue needs three things to work: a definition of what lands in it, one owner, and an age. Payments arrive short, arrive combined across clients, arrive without reference numbers, arrive against invoices you already charged back, arrive from a debtor whose payer name matches nothing in your system because the paying entity is not the entity on the rate confirmation. Each of those is a different problem with a different fix, and they are all one pile if nobody sorted them.
Watch the last one in particular. Freight payments are full of entities paying under a name other than the one on the invoice, and the fastest permanent improvement most posting desks can make is keeping a payer-alias list that maps the name on the bank statement to the debtor in your system. It is unglamorous data-cleaning work that removes a recurring exception rather than processing it again every week.
Unapplied cash is a balance, and it has an age
If unapplied cash lives in a suspense account, treat it the way you treat a receivable: as a balance somebody reads, with the items inside it aged by days.
Nobody worries about a payment that sits unapplied for a day. What does damage is the item sitting there for a month because it needs a conversation with a debtor that nobody scheduled. It distorts what the client sees, it distorts what your aging says, and the older it gets the less anybody remembers about it.
The International Factoring Association’s own monthly-metrics guidance names this directly. Writing in the IFA’s Commercial Factor, Becky Gibbs tells factors to “validate aging accuracy (disputes, offsets, unposted cash)” when reserve adequacy starts moving in the wrong direction. Unposted cash sits in that list next to disputes and offsets for a reason: all three make an aging report describe a book that is not the book you have.
Put the unapplied balance and its oldest item on the same monthly report as the metrics that matter. A number nobody reports is a number nobody works.
Short-pays are a coding problem first
A short-pay is a payment that also happens to be a message, and whether you hear the message depends entirely on what gets typed at the moment of posting.
Our collections guide covers the decision itself, which deduction was owed and which one to pursue, and we are not restating it here. The posting-desk half is narrower and it is upstream of everything else: the deduction has to be coded for why it happened, at the time it is applied, by the person applying it. Rate discrepancy, detention denied, shortage, duplicate claim, unauthorized chargeback, accessorial not approved. A code list of six real reasons that people actually use beats a list of thirty that all get posted as “other.”
That coding is where your dilution number comes from, and dilution read by reason code is a different instrument from dilution read as a single percentage. One tells you the book lost two points. The other tells you one debtor took the same unauthorized deduction ninety times and nobody escalated it, which is a conversation with that debtor rather than a fact of life.
The misapplication between two clients
This is the failure mode that belongs to factoring and to almost nothing else, and it is worth naming plainly so a new posting clerk understands the stakes.
Apply a payment to Client A that belongs to Client B and two things are now wrong at once. Client A’s invoice shows paid when it is still open with the debtor, so it drops out of collections and nobody chases it. Client B’s invoice is still outstanding on your books while the debtor has in fact paid it, so you may be chasing a debtor who owes you nothing, or holding a reserve you should have released. The error is self-concealing, because both accounts look internally consistent.
It surfaces in three places, usually in this order: a client asks where their reserve is, a debtor disputes a collections call by producing proof of payment, or the bank reconciliation refuses to tie. The first two are your clients doing your quality control for you, which is not where you want it done.
Two controls keep this honest. Corrections get made by reversal and reapplication with a reason recorded, never by silently editing an applied payment, so the history survives. And a payment that cannot be confidently matched to a client stays in suspense rather than getting posted somewhere plausible to clear the queue. A clerk under volume pressure will otherwise make the reasonable-looking guess, every time.
Reserve release is what the client actually experiences
Everything above is internal until it reaches the one moment the client feels. The reserve.
Our guide to advance rates, fees and reserves covers how the reserve works through the normal cycle. Cash application is what triggers it: the reserve on an invoice releases when the invoice is settled, and an invoice does not settle while its payment is sitting unapplied. So a posting backlog is not an internal inefficiency that stays internal. It shows up in a carrier’s bank account as money that did not arrive, and the carrier has no way of knowing whether the debtor paid slowly or your desk did.
That is worth saying to the team in those terms. The posting queue is a client-facing process wearing a back-office costume.
Reconcile daily, not at month-end
The control that holds all of this together is boring and it is daily: reconcile what the bank received against what your system applied, every day, and match both to the remittance records behind them.
Daily matters because the fix is cheap while the information is fresh. A payment you cannot identify today is a phone call to a debtor’s accounts payable contact who remembers sending it. The same payment three weeks later is an archaeology project, and the person who could have explained it has moved on to the current month’s problems. Daily reconciliation also catches the thing that has nothing to do with posting accuracy: a payment that should have arrived and did not, which is the earliest signal that a debtor is stretching, or that somebody was paid who should not have been. When payments start landing in the wrong place entirely, the mechanism is the notice of assignment and that page covers it.
None of this requires a particular tool. It requires the reconciliation to be a defined task with a named owner and a completion state, rather than something the back office does when the day allows.
What the field exam reads
There is an external audience for all of this, and it shows up once or twice a year with a checklist.
Our funding-stack guide puts the question the way a lender’s field examiner asks it: “Does your aging in the system reconcile to your aging in the report you just certified?” That reconciliation is downstream of posting and nothing else. A clean posting desk makes the borrowing-base certificate a report you run. A messy one makes it a week of reconstruction, and the examiner is reading the reconstruction, not the explanation.
Which is the commercial argument for spending real attention on the least visible function in the building. The people who decide how much you can borrow are reading the output of your posting desk, whether or not anyone in your shop thinks of it that way.
Who owns this
In a small shop, posting is one person alongside four other jobs. Our staffing guide puts cash posting in the back office with funding operations, reserve accounting and reporting, and calls it the function most likely to be understaffed, because it produces no new clients and gets noticed only when something breaks.
Two practical notes on that. The person who posts cash should not be the only person who can research an exception, or every unclear payment waits for one calendar. And the definitions, the code list, the payer-alias table, the suspense policy, need to be written down somewhere other than that person’s memory, because the cost of this function is almost entirely in what happens when they are out.
We are not going to tell you posting discipline prevents losses. It does not. What it does is make your aging true, your dilution readable, and your reserve releases defensible, and those three are what everything else in the shop is being decided on.
Where this stops being operational
FRC works on process. There is a line past it, and here the line is an accounting one.
How you recognize revenue, how a suspense balance is presented in your financial statements, when an item should be written off for accounting purposes, and the tax treatment of any of it are questions for your CPA. FRC is not an accounting firm, gives no accounting opinion, and nothing here is accounting or tax advice. Our operations audit is an operational read of how the work runs, which is a different exercise from a financial-statement audit and does not substitute for one.
Where an outside read fits
Posting problems are rarely posting problems. They are usually a payer whose remittance detail nobody retrieves, a code list nobody maintained, an exception queue with no owner, or a reconciliation that got skipped during a busy quarter and never came back. Each one is small. Together they are why the aging does not tie.
FRC’s 90-Day Operational Audit reads six domains, collections, onboarding, risk, technology, staffing and financial reporting, and ends in a written assessment with a prioritized 12-month roadmap and no long-term commitment. Cash application sits across three of those, which is the usual reason nobody owns it.
FRC’s founder, Renee Williams, built a freight factoring company from the ground up over 25+ years, leading credit and underwriting operations and building the reporting and back-office infrastructure that decides whether the numbers in a month-end pack are real. The operators we have worked with, MinWest Financial and MyFactor among them, came in understanding finance and not the operational realities of transportation factoring. Call 800-648-5450 and Renee picks up directly.