How to automate reconciliation for service reps

You do not need to know how any of it works underneath. You need to be able to say what a good morning looks like.

Write down five things, the way you would explain them to a new hire on their first day.

• The site. Which portal, and what your team uses it for. A carrier portal, a payer portal, a supplier network, a client system, a state filing site.
• The pull. Which report or statement, and which dates. "Yesterday's commission statement." "The remit file posted since the last run."
• The reference. What you check the portal against, and how your team gets that list out today. You hand that list over. The system your team works from stays untouched.
• The match key. The field that ties one row to another. Policy number, claim number, invoice number, order number.
• The exception. What makes a line worth a person's attention. Something missing, a status that moved, an amount that does not agree.

Then write the whole thing as one paragraph, the way you would say it out loud:

> On weekday mornings, before the team signs on, sign into the commercial lines carrier portal. Open commission statements and take the newest one. Match the policies on it against the list we send you, by policy number. Compare written premium and commission. Where both agree, list the policy as cleared. Where a policy is on the statement and not on our list, or the amounts do not agree, list it as an exception and carry the policy number, the insured name, the statement date and both amounts.

That paragraph is the job. Nothing in it is technical and nothing in it is vague. Read it back to the person who does the work today. If they would not recognize their own morning in it, it is not finished yet.

That is why this work stayed manual. Systems that publish one get connected by an integration project and then nobody thinks about them again. Portals do not publish one, and nobody is funding the work to change that. The portal is fifteen years old and it will still be there in fifteen more. So the job lands on a person, and next month it lands on the same person.

That is the part we take. You tell us the site and the job. We go through the site, build the flow, hold the login, run it, and keep it working when the site changes. Your team stops opening the browser.

You sign in once yourself, on the real site, inside a Rindler browser. For most sites Rindler never sees your password. Some sites tie a login to one live browser, and there it is per task.

This is where the setup effort goes, and it is the part that decides whether the output is worth opening.

Cleared is the easy half. The key matches, the amounts agree, there is nothing left to do. Say what "agree" means in your world: exact, or inside a tolerance your team has always allowed and never wrote down.

Exceptions are where the work is. Name the kinds you actually chase.

• On the statement, missing from your list.
• On your list, missing from the statement.
• Both present, the amounts do not agree.
• Both present, the status does not agree.
• Dated outside the period you are closing.

Then say what an exception row has to carry, because that row is the thing a rep opens in the morning: the portal it came from, the statement date, the key, both amounts, both dates, and which kind of exception it is. A row that names the difference gets handled before lunch. A row that says "look at this" starts a second investigation.

Say how you want the rows grouped, too. By portal, if different people own different carriers. By dollar impact, if the biggest break gets worked first. By age, if the ones that have been sitting are the ones that hurt. Grouping sounds cosmetic. It decides whether the queue gets worked top to bottom or picked over.

Pick the time and the cadence. Weekday mornings before the team signs on. Monday and Thursday. The first days of the month, when close is the only thing anyone cares about.

A schedule is a clock, not a trigger. The run happens at the time you set and brings back what the portal held at that moment. For reconciliation that is exactly the behavior you want, because the question you are asking is not "did something change over there", it is "does today's picture line up with ours".

Set a cutoff in the same breath, so the run and your team are reading the same day. Write it into the job: everything posted before midnight local time.

Structured records, on the cadence you set. Cleared rows and exception rows, the same shape run after run, carrying the fields you named. That is the deliverable: a list in a fixed shape, so the first thing a rep does in the morning is work the queue instead of building it.

Every run comes back with what the portal returned, and a run that could not finish comes back saying so, with the portal and the step named. You are not reconciling against a file that never arrived.

Nothing is moved, filed or paid unless your team instructs it. This work reads and it compares. The judgment call, the endorsement, the phone call to the payer, the write-off, all of that stays with the person whose name is on it.

Reconciliation without an owner turns into a report nobody opens. Pick the person who will read the exception rows and decide what happens to each one, and give them the authority to change the rules, because they will want to almost immediately. The tolerance is too tight. One exception kind is noise. A field they need is not on the row.

Changing the job takes a sentence. You say what changed, in the same plain words you used the first time, and we change it.

Portals get redesigned without warning anyone. Teams that run this kind of work get burned by it, which is why the question under every other question is who fixes it when the page moves.

We do. Centrally, once, for everyone on that site. You do not file a ticket and you do not pay for the repair.

That is the boundary worth understanding before you commit a daily process to this. A portal being difficult is our problem to solve. It is not a reason the work quietly comes back to your team.

Pick one job. The narrowest, most repetitive reconciliation you have, the one a named person does on a named morning. Not the hardest one, and not the one with the most money moving through it. The boring one that never stops.

Write the five lines from the first section, then tell us the site and the job. We go through it. That is the work.

How it works is the same story with the steps in it. The use cases show what this looks like on other kinds of portal work, once your team has stopped doing it by hand.