Solution and case study
Third-party billing from Prophet 21 that catches the error before the bank does.
Third-party billing fails when the file that reaches the bank or billing partner breaks one of their rules. I build applications that pull billing data from Prophet 21, check it against the partner's rules and your own, and show the operator exactly what to fix before anything is sent. The result is payment that arrives on time and a process more than one person can run.
Why this process is riskier than it looks
Third-party billing sits in an awkward place. It is not quite accounting and not quite IT. It is often built once, years ago, by someone who understood both sides, and then left alone because it worked.
The risk builds quietly. The partner updates its requirements. The people who built the process move on. One specialist learns its habits and becomes the only person who can tell a good file from a bad one. From the outside it looks like a routine task. In reality a meaningful share of your cash flow depends on one person noticing a problem in time.
Case study: a wholesale distributor
The situation. The distributor’s third-party billing ran on a process more than a decade old. The people who created it were long gone. The file protocol was so dated that the bank had retired it for everyone else and was keeping it alive for this one customer. On the distributor’s side, a single subject matter expert made sure each transmission was accurate.
What was at stake. A failed transmission meant the bank could not pay. Deposits were delayed, potentially millions of dollars at a time, and the first sign of trouble was often a phone call from the bank.
What I built. An application that reads the billing data directly from the Prophet 21 database, using efficient SQL for the complex pieces the billing partner requires. It understands the business rules of both the partner and the distributor. When something is wrong, it tells the operator what and where, before the file is sent. The approach works the same way against on-prem or cloud P21.
The result. The process no longer depends on one expert. A primary operator and several trained backups run it. Errors are caught before they become exceptions. The application is easy to update when a rule changes or a new requirement arrives. It went live in about four weeks.
The principle behind it
The old process was reactive. It sent the file and waited to hear whether something was wrong. The new one is proactive. It assumes something will eventually be wrong and makes sure a person finds out first, with enough information to fix it. That shift, from hoping to knowing, is what protects the cash.
“When we learned Heath was available to help us with our project, we jumped at the opportunity. He has a talent for making complex systems simple and reliable. His contributions were essential to the success of our project, and we highly recommend him.”
Scott TindleDirector of Customer Support, Midwest Equipment & SupplyQuestions
Our partner uses a different format. Does this still apply?
Yes. The format is the easy part. The value is in encoding the rules and surfacing errors early.
Do you need our P21 database?
Read access to the billing data, through SQL or the API depending on your environment.
How long does something like this take?
This project took about four weeks. Yours gets its own estimate once I understand the process.
Request a call back
Does your billing depend on one person and an old file?
If it does, I would like to hear about it.
- One conversation, no obligation. There is no charge and no pitch.
- A plain answer. If it is not feasible, or I am not the right fit, I will say so.
- The first 30 days are guaranteed. If you are not satisfied and I cannot make it right, in your opinion, you get your money back.