How We Handle High-Volume Placement Intake

The problem

Picture yourself keying a thousand invoices into a collections system by hand. Business name, address, amount owed, invoice date, contact information, etc. Each field read off a scanned page and typed into a form, one at a time, a thousand times over. Then doing it again the following week when the next batch lands. That was what new placement intake looked like here for years, and the load it put on our admin team was significant.

Volume by itself is something you can staff around, but what made it heavier was the variety. One client may drop a batch over FTP on a schedule. Another might export a spreadsheet straight out of their AR aging system. A scanned invoice shows up for one account, and an account statement for another. Our admin team had to know how to read each of those correctly before a single field could go in. That knowledge took time to build, they had to make sure every necessary field was captured, so our collectors had the best chance of success.

The hard part

The grind was constant, going back and forth between screens or glancing at a printed invoice copy. Read a value off the invoice, enter it, return to the invoice for the next field. Typing turned out to be the smaller half of the work. The rest was confirming what had just been entered. Was this the business that owed the money, or a parent company with a similar name? Did the address on the invoice match where the debtor actually operated, or was it a billing office three states away? Did the zip code get entered correctly? How about the fees, did you get those? Phone numbers needed checking too, since a disconnected line looks exactly the same as a working one on paper.

Answering some of those questions meant leaving the entry screen, looking the business up, checking what came back against the document, and then returning to finish the record. A few minutes per account. Across a batch of a thousand, and that is days of work. Skipping it would have cost more than it saved. A wrong number burns the first contact attempt, and first contact is when a debtor decides how seriously to take the file.

So we set out to automate the checking as much as the typing.

What we built

Our pipeline reads the file, pulling text off a scanned page or reading values straight out of a structured file when one is available, like an invoice or statement. Then it maps what it finds into a fixed set of columns which we use for every account: business name, contract number, email, phone, total amount due, and the date of the last invoice. A placement built from a scanned invoice ends up in the same shape as one built from an FTP batch. That consistency is what lets every account we place go onto our collections management system without a manual reshape first.

Getting to that point required accounting for how differently our clients' documents are put together. One client's real service address sits in the middle of the invoice rather than at the top where the billing address goes. Another sends invoices where the vendor's shared accounts-payable inbox sits in a field that looks like a debtor contact, so those get skipped during the lookup. Those kinds of quirks used to live in the head of whichever admin staffer had handled that client before. Each one is now a rule the system applies every time that client sends a file, regardless of who is working the desk.

We then run verification on top of that process. Simple checks first like double checking zip codes, state abbreviations, amounts, and dates, each validated before anything moves toward placement. Then the system looks up the phone number and address against the business's public web footprint and grades the match with a source citation attached. That lookup used to be entirely a manual step our admin ran one business at a time, and we still look up many businesses manually, though we now have the ability to automate that process as we deem fit.

Every placement still gets a final review from our admin before upload. Anything the system cannot read confidently gets filled in by a person. That review step is not optional and was never designed out.

We rolled it out on a single client's batch of 140 placements and after a short wait, it cleared with no issues. The file was then imported into our collection management system where it was worked by the collectors. This first completed batch gave us a real baseline, and once the numbers and contact details coming out lined up with the documents going in, we added a second client, then a third. Each new client introduced a format we had not handled before. Each one went into the rule set. We have been adding to it since.

The result

Our admin team no longer builds placements solely one field at a time. Entry and verification became a review step. Accounts reach the platform faster, which means the account manager starts working the file sooner. On a stalled receivable, that timing matters greatly.

For our clients, the more significant change is that getting accounts to us stopped being something to plan around. A credit manager sitting on a backlog of stalled accounts in four different formats used to face real work just getting those accounts out the door. The answer to how to send them to us is now: send them however they already exist. A client can place their full volume on day one instead of reshaping how they operate first.

When a new client arrives with a format nobody here has processed before, the work on our end is extending a rule set. On their end, it is sending the file.