What this is

Client Deposit Tracking replaces the per-client payment posting reconciliation spreadsheet. Instead of one workbook per client per year, there is one register. Clients tell us what landed in their bank account; the payment posting team works one queue across every client.

There are two sides. The client side is where a practice reports a deposit. The internal side is where the posting team works. They are the same application and the same data — a client sees only their own practice, and only the part of it they need.

Live. Staff sign in at https://deposits-internal.revenuecyclesolutionsllc.com with their work account — no separate password. Practices use https://deposits.revenuecyclesolutionsllc.com, which is a different address on purpose: the internal one will not open for them.

The rule this application enforces

Everything in here follows from one rule, so it is worth stating before anything else.

A cash remit is posted only once the deposit is verified. The client’s entry in this application is that verification. Two conditions have to be met before the posting team may post a payment: the deposit is verified, and a remit is in hand. If either is missing, the row waits and it ages.

A zero-pay, denial, or adjustment-only remit is different — no cash moved, so there is nothing to verify, and it is clear to post straight away. Log it anyway: the row still carries a reason, and those reasons are the point.

So the rule splits cleanly on one question, did any money move?

For client practices

Reporting a deposit

Sign in and you land on Report a deposit. It asks for five things:

Then Submit deposit. You get a reference number and the row is visible to your RCS team immediately.

If you have the paper EOB, attach it. Drop the PDF or a photo into the attachment box. Two things happen: we stop needing to chase you for it, and the remit question answers itself, which means we can post sooner. This replaces emailing it or putting it in a shared drive folder.

Several files are fine. Pick them one at a time or all at once — each one is added to a list rather than replacing the last, so a remit spread across three scans in three folders works. Each has a Remove if you pick the wrong one.

Notes are for context, not for patients. No patient names, dates of birth, account numbers, or anything that identifies a person. If you need to tell us something about a specific patient, that belongs in a HappyFox ticket, not here.

Sending a day’s banking instead

Easier when several land at once. On Report a deposit, under the form, tell us the banking day and attach what your bank shows for it — a PDF, a screenshot, a spreadsheet, whatever comes out. You do not need to tidy it up, pick out the insurance payments, or put it in any particular shape. We read it and enter the deposits for you.

We only look at money coming in from payers. Payroll, rent and transfers on the same page are ignored, and you are welcome to black them out before sending. We are asking for a page that shows more of your business than we need, and you should know what happens to the rest of it.

Up to eight files at a time, twenty megabytes each. PDF, Excel, CSV or an image. If one of them is a type we cannot open, nothing is sent — you get told which, rather than discovering later that part of it never arrived.

Days you have sent below the form shows what happened to each one:

• With the team — we have it, nothing needed from you.
• Entered — with the number of deposits and the total. Click through to see them. If that count looks short, tell your CRR; it is the fastest way to catch something we misread.
• Nothing from payers — we read it and there was no payer money in it. A real answer, so you know we looked.
• Withdrawn — you pulled it back.

Days your RCS team added for you — because you emailed or phoned them in — appear here too, marked added by your RCS team. They are listed so you can see we have them and do not send the same day twice.

Withdraw appears only on days you sent yourself, and only while one is still With the team. Once we have started keying it, the file is the source for deposits that now exist and pulling it would leave them with nothing behind them. Withdrawing deletes the file.

Cash reconciliation

Cash reconciliation is your year, month by month: what reached your bank, what we posted against it, what was never ours to post, and what is still open. The last row is the year.

Pick a month to narrow everything to it, or leave it on the whole year.

Open $ with us is money we are working. Open $ with you is money where we need something from your side — usually an EOB. If that column is empty, nothing is being held up by you.

Underneath is why the variance is open, by reason. That is the table worth reading: it says why cash is unreconciled rather than only that it is.

Variance is deposited less posted, less anything that was never ours to post — a card settlement, a patient payment, a transfer between your own accounts. So it means cash not yet applied and nothing else. Deposited still totals every dollar that landed; money that is not ours is named in its own column rather than hidden.

My deposits

My deposits is your register. Everything you have reported, what we posted against each one, and the difference if there is one.

The section that matters is at the top: Waiting on you. Those are the deposits we cannot finish because we need something from your side — usually the EOB, because we can see the money but have nothing to post it against. If that section is empty, nothing is being held up by you.

Filtering. Month, and a search across payer, reference and reason. Each section filters separately, and any section hiding rows says so with a count — a short list and a filtered list should never look the same.

“Not a payment we post” in the Where it stands column means exactly that: money that reached your bank which is not a payment for medical services, so there is nothing for us to post against it. A card settlement, a patient payment taken at the desk, a transfer between your own accounts. Nothing is needed from you and nothing is wrong — the deposit stays on your register with its figures unchanged so the money is still visible and still counted.

Above that, sometimes, is a different question. If a payer tells us they paid you and we cannot see the money arriving, you will be asked about it directly. The heading says how many there are and how much money they add up to, and each one is a line — payer, amount, date, reference — that opens when you click it. Only you can see your bank, so only you can answer these.

Two answers, and either is useful:

• Yes, it landed. Enter the date and the amount your bank shows. Enter what your bank shows even if it does not match the payer — that difference is exactly what we are looking for, and correcting it to match would hide the problem.
• No, nothing arrived. Tell us and we chase the payer. Nothing further is needed from you.

One deposit may appear as several rows. If a single credit on your statement was actually several payers paying at once — a same-day ACH batch does this routinely — we split it into one row per payer, so each has its own difference and its own reason instead of four different problems sharing one line. Those rows say part of your 10,000.00 deposit on 07/01 underneath the date, and the original credit is not listed again: showing both would put the same money on your register twice.

While we are still working out which payers make up a credit, the remainder appears near the top as Still being matched to payers, with what you reported, what we have matched so far, and what is left. Nothing is needed from you. It is there so your register still adds up to what you reported — the page says that total at the bottom.

Rows under With us need nothing from you; we are working them. Settled is everything that is done.

For the payment posting team

The queue

You land on Queue: every open row across every client, oldest first. Not one client at a time, and not one file at a time.

Across the top: how many items are open, the total unreconciled cash, how much of it is owned by the client versus owned by us, and the age of the oldest item. Owner = Client is the ask — that is the number to take into a client conversation.

Filters apply as you pick them — there is no Apply button — and Clear puts everything back. Filter by client, CRR, variance status, reason, owner, assignee, whether it has been posted, and whether a remit is overdue a deposit. The CRR filter matters as pods come in: it narrows the queue to the clients a given CRR covers.

Search takes an amount as well as a name. Type 546.37 and you get the row that reached the bank for that. You do not have to type all of it: 546 finds everything from 546.00 to 546.99, and 546.3 narrows that to 546.30–546.39. Dollar signs and commas are fine, so a figure pasted straight off a statement works. Searching by amount does not stop it searching by client, payer and reference at the same time — a reference that happens to be all digits still finds its row.

Editing a row without leaving the queue

Click anywhere on a row and it opens underneath itself. Five fields are editable there — Posted, Reason (and how much of the difference it accounts for), Owner, Status and Assignee. Save, and you come back to the queue with your filters still applied. Cancel closes it and changes nothing; so does pressing Escape.

Those five are our side of the row: what RCS did about the money and who is carrying it. Entering a posted amount dates the row today, so it counts as posted — change the date on the full record if it was posted earlier.

What is deliberately not editable from the queue:

• Payer, Reference and Deposited. These are the practice’s own account of the deposit, and correcting them is a heavier act than working our side — the deposited figure is what every variance on the screen is measured against. They live on the full record under As reported, next to the attachment and the history, where a change is visible in a way it never is in a list of a hundred rows.
• Variance and State are worked out from the other figures. There is nothing to type, and a variance you could type would be a number able to contradict its own inputs.
• The deposit date. The daily close groups by it, so changing it moves money between days — worth doing on the full record where you can see what you are moving. Use Open the full record.

Opening a row also gives you Not ours to post — see below.

A row marked Bank line is one credit that has been split between several payers, and it is on the queue only because part of it has not been allocated to one yet — the row says how much. It has no posted box, because a bank line is not a payment: its payer parts are rows of their own, each with its own posting. Fix it with Open the full record, where the parts are listed and can be added to or corrected.

One row opens at a time, on purpose: several at once buries the list you are working and makes it easy to type into one row while reading another. View still opens the full record as it always did, and the filters follow you there and back.

Variance status is about the variance, not the deposit. Open, Researching, Escalated to Client, Resolved — the workbook’s vocabulary for working a difference. Whether a row has been posted is a separate question with its own filter, because the posted date is the fact and a dropdown value would be a second answer able to disagree with it. A row with no variance shows a dash there rather than “Open”: there is nothing to be open about.

Two banners appear when they apply. One when a remit has been waiting longer than the threshold for its deposit; one when open work is assigned to someone PDS no longer lists as staff. Both name the problem, and both link to the rows.

CRR comes from PDS, not from anything typed here. It is the person assigned to the client’s active platform — the same definition PDS’s own client portal shows the practice as their representative, so there is one answer to the question rather than two. A client with no platform assignment in PDS reads as unassigned, which is a real state and not a loading failure. Use Refresh name, status and CRR from PDS on the client page after a reassignment.

The Clients filter defaults to “Active in PDS.” Terminated practices are still here and still hold every deposit they ever reported — switch to All, including terminated, or pick the practice by name, and their whole history is there. Nothing is ever removed when a client goes inactive.

Times are Eastern. Everything is stored in UTC and shown in Eastern with the zone named, so EDT in summer and EST in winter. Deposit dates are dates, not times, and are shown exactly as reported — they are not shifted.

Age is computed every time the page loads. It rises whether or not anyone opens the screen. In the spreadsheet the age only updated when somebody had the file open, so an item could sit for a month without anybody’s number moving.

What the states mean

Working one deposit

Open a row. The left is what you fill in; the right is what the client reported, plus the full history.

Record the posted date and posted amount. Variance calculates itself as deposited minus posted minus legacy. Legacy posting amount is only for migration-era clients.

A posted amount can be negative. When a recoupment takes back more than the payer sent, the net posting is below zero — type it with a leading minus, as -100.00. The variance widens rather than closing, which is correct: the practice banked money we then handed back, so there is more to account for, not less. Then use How much the reason covers to record the recoupment against it, and what is left is the part still worth chasing.

Pasting works too. (100.00) — the way a spreadsheet writes a negative — is read as -100.00, so a figure copied out of a report keeps its sign instead of quietly arriving as a positive.

The deposited amount is the one figure that cannot go negative. A bank credit of minus five hundred dollars is not a deposit, and the form refuses it. The sign belongs on our side of the row — what we posted — and nowhere else.

Remit location is where you note that a remit arrived and from where. That note is what satisfies the second half of the posting gate, so it is not bookkeeping — it changes whether the row is clear to post.

Unknown is one of the choices, and it counts as not having a remit. It is there so you can say “we cannot tell” without having to claim either a channel nobody has checked or that the remit never came. A row marked Unknown stays in Awaiting remit and keeps getting chased — which is the right way round. A row wrongly left waiting gets looked at; a row wrongly marked ready goes quiet.

If the variance is not zero, it needs three things:

• Reason — from the fixed list. Not free text, because these get counted.
• Owner — RCS or Client. Who has to act to clear it.
• Status — Open, Researching, Escalated to Client, or Resolved.

How much the reason covers is optional and worth using. Leave it blank and the reason accounts for the whole difference, which is how most rows work. Put a figure in when it only explains part: record a recoupment of 120 against a difference of 2,310 and Still unexplained shows the other 2,190, which is the number actually worth chasing. Without it, one true reason quietly closes the question on money nobody has looked for.

Processed by Anatomy

A tick box on every deposit, off until somebody ticks it. It is on the right of the deposit page, below Not ours to post, and on the queue it is the last field when you open a row, with an Anatomy column showing a tick or a dash so you can read a run of rows without opening any of them.

It is only a marker. It changes no figure, does not affect whether a row is clear to post, and does not make a variance go away. Ticking it is recorded in the row’s history with your name against it, the same as any other change.

You can filter the queue by it: the Anatomy box above the list offers Processed and Not processed, so you can work down whichever you need.

Practices never see it.

Seeing what a practice sees

Client mirror, in the top navigation. Pick a practice and you get a read-only copy of their own cash reconciliation — rendered from their template and their data, so what you are reading is what they are reading. Useful on a call.

There is a shortcut too: filter the queue to a client and a See their view button appears beside the filter.

Nothing on it can be changed and the practice is not told you looked, though the access log records it. It replaces signing in as the client, which put our actions in their audit trail.

Correcting what the client reported

The As reported panel on the right shows what the practice told us. Most of the time you are only reading it, so it stays as plain values — click Correct what was reported to open the form. If the practice keyed 546.37 as 564.37, or named the wrong payer, fix it there: deposit date, payer, reference and amount.

Every change is written to the history with the old value beside the new one, so what it used to say is never lost. Changing the amount changes the variance, so treat it as a heavier edit than your own side of the row.

Who entered it and when cannot be changed, and neither can the source. That is the audit trail, and an audit trail you can edit is not one. Attachments have their own Add and Remove. Remit location is set on the left of the screen and only there.

Money that was never ours to post

Sometimes what hit the bank was never going to be posted: a card settlement, a patient payment taken at the desk, a transfer between the practice’s own accounts, interest, a refund from a payer.

Use Not ours to post, on the deposit page and in the queue’s row editor. Pick the reason, add a note if the reason asks for one, and the row leaves the queue.

Marking a row not ours to post now also sets its status to Resolved, because there is no longer a variance question to answer. Putting it back in the queue returns it to Open.

Nothing is zeroed. The old way of handling this was to type a posted amount equal to the deposit so the variance came out at zero — which recorded as posted money that was never posted, and corrupted the one figure that answers “what did RCS actually post?”. Marking a row not ours to post leaves the deposit, leaves the variance and simply stops asking the question, so “how much of what reached their bank was not ours?” stays answerable.

If you mark the wrong row, Put it back in the queue undoes it. Both actions are in the history and the access log.

Administrators manage the reason list under Admin → Not ours to post.

Everything is recorded. Who changed what and when is written by the application, not typed. Downloading an EOB is recorded too, because it is patient information.

Splitting one deposit between several payers

A practice’s bank shows one credit of 10,000. It is actually four payments: BCBS 2,500, UHC 2,500, Medicare 2,000 and XYZ 3,000. One reference, four remits, arriving separately and probably later. A same-day ACH batch or a lockbox sweep does this routinely, and at some practices it is most of the volume.

The practice reports what their bank shows, because that is what they can see. You split it when the remits arrive.

Use Split into payers, on the deposit page. It is on the full record only — this is a structural change to somebody’s money, and the queue’s row editor is deliberately five fields. Click Split this deposit, name each payer and what they paid, and use Add another payer if four is not enough. As you type, the panel shows what you have allocated and what is left.

Each part becomes an ordinary row with its own payer, remit location, posting, variance, reason and owner — which is the whole point. The obvious shortcut, one row with payer Multiple and a posted amount of 10,000, is one reason field for four different problems: if BCBS underpaid by 200 and Medicare recouped 150, the row can only carry one of those, and the variance-by-reason table the practice reads reports nothing.

They do not have to add up. A remainder is a finding, not an error. It saves, and the difference is shown as Not allocated to a payer — either a remit has not arrived yet or one of the figures is wrong, and both are worth chasing. While that figure is anything other than zero the bank line comes back into the queue, marked Bank line rather than as a payment, with the unallocated amount on the row. When it reaches zero it leaves again.

What follows from a split:

• The bank line stays and carries what the practice reported. That is the one figure in this application nobody derived.
• It stops being postable. There is no posted box on it, on either screen, and the server refuses one. Post the parts.
• Parts inherit the date and reference and can be corrected afterwards on their own records, in As reported.
• The statement stays on the bank line and every part links back to it. The document covers the whole credit, and copying it onto four rows would multiply the patient information.
• A part can be split again. A split is an allocation, and allocations get corrected.
• If the practice later corrects the credit, correct the bank line — the unallocated figure moves and says so. Do not unsplit and start over; the parts are somebody’s work.

Unsplit removes the parts and puts the row back in the queue as an ordinary deposit. It is available only while none of the parts has been posted and none of them carries a file — after that, those postings and files are the record. A deposit that has already been posted cannot be split at all; unpost it first.

Splitting and unsplitting are both written to the history and the access log, with the unallocated figure at the time.

The attachment

If an EOB has been attached, the deposit page shows it. A PDF or an image is previewed on the page so you can read it against the numbers without leaving.

• Open in a new tab — full size, for reading properly.
• Download — saves the file under its own name.

Both are recorded in the access log. This is patient information, and who looked at it is part of the record.

Assigning a deposit

Assignee is a list of current RCS staff, taken from PDS. It is not a list anyone maintains here, so it cannot go stale: someone who leaves stops being offered as soon as PDS says so.

If a deposit is already assigned to someone no longer on the list, their name stays and is marked. Reassigning is a decision for a person to make, not something a roster refresh should do quietly.

Correcting or removing a day of banking

Open the submission and use Correct or remove this submission.

The banking day and the note can be changed whichever side uploaded it — a practice sending Tuesday’s banking labelled Monday is the common case. Deposits already keyed keep their own dates: those came off the statement line by line, not off this label.

Remove this file next to a document drops that file. The row stays, so a deposit keyed from it still says where it came from; only the bytes go.

Deleting the whole submission is refused once any deposit has been keyed from it. Those deposits are the reconciliation record and the submission is their provenance. The message says how many and what to do — remove those deposits first if it really was loaded in error.

Reasons, and who maintains them

Admin → Reasons holds both maintained lists: variance reasons (why a posting and a deposit differ) and not ours to post.

Add, rename or retire without a deploy. Retiring is not deleting — the label leaves the picker and every deposit already carrying it is untouched, because a deposit stores the text rather than a link. Renaming changes what people pick from here on and deliberately does not restate past decisions.

Variance reason wording is read by clients. It appears on their register against any deposit with a difference, so if an entry reads badly to a practice, reword it here.

Daily close

Daily close shows one client, one day per row: deposited, posted, not ours, variance, and whether the day is closed.

A day closes in one of two states. Posted equals deposited, or every difference is logged with a reason, an owner, and a status. A non-zero total does not by itself block the close — a variance that is owned and aging is an acceptable end state. An unowned open row is not.

Not ours is money that reached the bank and was never going to be posted — a card settlement, a patient payment, a transfer between the practice’s own accounts. It sits in its own column rather than counting as a difference, so Variance means cash we have not applied and nothing else.

That is a deliberate change. Before it, a 2,880 card settlement left a closed day reporting a 2,880 variance, and a day marked Closed sitting beside a large difference is how people learn to stop reading the column. Deposited still totals every dollar that landed — the money is not hidden, it is named.

Zero-cash remits appear here on the day they were posted. In the spreadsheet they had no deposit date, so they never showed up in any day’s close at all.

Reasons

Reasons counts every variance reason across the book, in count and dollars.

This is not a report to read and close. Several of those reasons are structural and permanently fixable — an ERA enrollment gap closed once stops generating variances forever, and a portal-only payer is a known condition to design around rather than rediscover every month. Driven toward zero, this list is the work list.

Posting lag sits alongside it: the median and 90th percentile number of days between money landing and the payment being posted. Watch the median. Because posting now waits on the client reporting the deposit, a climbing median is the early sign that the rule is holding the team up.

Entering a deposit for a client

Enter for a client covers three different situations. Two checkboxes at the top decide which one you are in, and ticking either switches off the fields that no longer apply.

A deposit the client told us about. Nothing ticked. Use it when the money is reported by phone, email, or a HappyFox ticket. Record where the information came from — the row shows that you entered it, not the client, so a month later it is clear they never reported that one themselves.

A zero-cash remit. Zero pay, denial, or adjustment only. No deposit fields, and clear to post straight away.

A remit with no deposit reported. The payer says they paid and we cannot see the money. Record what the remittance says — the amount, the date, the EFT or check number — and the row waits rather than posting.

That last one is a different fact from a deposit, and the application keeps them apart on purpose. The remit amount is what the payer says they sent; the deposit amount is what the practice says landed. The gap between those two is the variance this whole application exists to find, so they never share a column.

When a remit arrives and the money has not

The row sits in Awaiting deposit and ages. It cannot post: the deposit is the half that is missing.

The practice sees it at the top of their own register, with the two answers they can give — yes it landed, with the date and amount from their bank, or it has not reached my bank.

• If they confirm it, the row becomes an ordinary deposit and can be posted. If the amount they enter differs from the remit, that difference is kept. It is not an error to correct; it is the finding.
• If they say it never arrived, the row comes back to us as a Remit not received variance owned by RCS. From there the job is to chase the payer, not the practice — they have answered the only question they could.

The queue tells you what is aging. Past the threshold on the Settings page (three days to begin with), a banner names how many remits are still waiting and how much money they represent, with a filter to show just those.

The clock is counted from the remit date, not from when it was entered — if a remittance sits in an inbox for a week before anyone logs it, the payer’s clock started a week ago, and resetting it on entry would hide a delay of our own making.

Practices never see that countdown. They are told plainly what we need and nothing else. How long we have been chasing is a measure of our work, not theirs.

When the same money is on two rows

A practice may report a deposit through the ordinary form while the remit-first row is already open. That leaves two rows for one payment, and the queue says so: same client, same reference, two rows.

It is offered, never done automatically. Which two rows are one payment is a judgement, and a merge that gets it wrong destroys a deposit nobody reported twice.

Open either row and you get both side by side, then These are the same payment — merge them. The remit row survives, because it came first and it is what the practice was asked about, so the question and its answer stay on one record. The deposit date, the attachments and the history all move across.

Both amounts are kept. The payer’s figure and the bank’s figure stay as each side reported them — if they differ, that difference is the finding, not a discrepancy to tidy away. Pairs are matched on the reference alone for exactly that reason: requiring the amounts to agree would find only the pairs that did not need looking at.

A row with no reference never pairs with anything. Patient payment batches have no key, and guessing there would join two genuinely different payments.

Bank files

Days of banking practices have sent for us to key. The tab carries a count of what is still waiting — the only badge in the navigation, because a day nobody has opened is money nobody is reconciling.

Oldest banking day first. Banking day and Sent on are separate filters and it matters: Friday’s banking arrives on Monday, and a catch-up arrives as three days at once. Banking day answers is 08/04 reconciled?; sent on answers did anything come in today? Filtering by one when you meant the other hides work rather than showing none.

By default you see only what is waiting. Choose a status to look at history.

When they send it some other way

Practices email statements to their CRR, attach them to tickets, and read them down the phone. Add a day on a practice’s behalf on the Bank files page puts that into the same queue rather than leaving it in an inbox — pick the client, the banking day, and how it reached us.

It behaves exactly like one they sent, with two differences. The queue marks it by us so nobody has to guess who put it there. And the practice sees it in their own history as added by your RCS team — that is deliberate, because a practice who cannot see it will send the same day again and we will key it twice. They cannot withdraw it, since the file may be one only we still hold.

Keying one

The file is on the left, the entry form on the right. Work down the statement and add each payer deposit. Keying from a document open in another tab is where transposed digits come from, which is the whole reason this screen is split.

Enter what the statement shows even if it looks wrong. A difference between what the payer sent and what we post is exactly what the queue exists to surface.

Each row goes into the queue as you add it, marked keyed from the practice’s banking, and counts as confirmed. That is deliberate: confirming a deposit has always meant the practice telling us the money landed, and a bank statement is them telling us that in a more reliable form than a typed figure. It does not skip the posting rule — it satisfies the half of it the practice owns.

Finish with one of two answers:

• Finish — closes it, with the count of what you keyed. Refused if you have keyed nothing, because closing an unread file silently loses whatever was in it.
• Nothing from payers — you read it and there was no payer money in it. The practice sees this, so they know we looked. Refused if you have already keyed something.

Reopen undoes a finish that came too early. Use it rather than entering the rest somewhere else — a deposit entered outside the file loses the link back to where the figure came from, and that link is the point. A withdrawn day cannot be reopened; its file is gone.

Where a figure came from

Every deposit keyed this way points back at the submission it was read off. Six months later, where did this 1,234.55 come from? is one click to the statement page — better provenance than a typed entry has ever had here.

Searching does not look inside the files. Nothing is parsed; a person reads them. So the filters are on client, dates, status and who keyed it, and searching for a payer name will not surface the statement it appears on.

Admin

Administrators see an Admin tab; nobody else does. Behind it is a row of tabs — Overview, Clients, Staff, Assignees, Not ours to post, Settings, Access log — all of them about setting the application up rather than working the queue. Overview is a one-line description of each, and the counts on the tabs are live.

Practice sign-in. When somebody at a practice has no sign-in account, the Admin page names them and links straight to the client page that fixes it. It says nothing at all the rest of the time — no news is good news, deliberately. A permanent green “everyone is fine” panel is one people stop reading, and this one would be green almost always. If it ever reports that it could not check, that is not the same as saying someone has no account; reload before acting.

Clients

One list of every practice, whether or not it is set up here yet, with a State column saying which is which. Search by name or code — it filters as you type — and Show narrows to set up, not set up, or archived.

A client exists here only if it exists in PDS. Press Add on the row you want; the code and name come from PDS’s answer, never from anything typed here, so this register cannot drift into its own spelling of a practice’s name.

Practices that were already inactive in PDS before 08.01.2026 are never listed. They ended before this application existed, so they can hold no deposits. One that goes inactive after that stays available, because it may still have money to reconcile.

If PDS cannot be reached, nothing is added and you see the connection error rather than “no such client” — those are different problems and only one of them is about the client.

Inviting people at a practice

Open the client and add a work email. Cognito emails them a temporary password from deposits@certifiedrsllc.com; they set their own on first sign-in, and they can reset it themselves afterwards without anyone at RCS handling a credential. Replies to those emails land in the HappyFox Client Communication inbox.

Add at least two people per practice. One person on holiday should not stop deposits being reported.

Disable keeps someone’s history and stops them signing in — use it when someone leaves. Remove appears only for an account that has entered nothing, which in practice means an invitation sent to a mistyped address.

If someone has no sign-in account. Accounts are created at the moment you invite, so this only affects people invited before sign-in moved to Cognito in August 2026 — a closed group that shrinks to nothing once cleared. The client page names anyone in that state and offers a button that creates their accounts and emails each a temporary password. It skips anybody who already has one, because a second temporary password cancels the first — awkward if they are half-way through using it. Use the same button after any rebuild of the sign-in directory.

Staff

Internal accounts and who administers the application. Accounts appear automatically the first time someone comes through Cloudflare Access, so there is no invite step — Access has already decided who may be here.

Only the very first person ever became an administrator, so everyone else has to be made one. Use Set someone up before they sign in to have an account and its rights waiting for a new starter. That grants nothing by itself: Access still decides who gets through the door.

Search by name or email, and filter by administrator or not, and active or disabled. It defaults to active people — a leaver is disabled rather than deleted, because their entries are part of the record.

Assignees

Which RCS staff appear in the Assignee box on a deposit. The list comes from PDS, so a leaver stops being offered as soon as PDS says they have left, and a new starter is available the day PDS knows about them.

PDS has around seventy active employees and only a handful work deposits, so hide the rest. Hiding stops someone being picked; it does not reassign anything. Anyone already assigned keeps their name on that row.

Not ours to post

The pick list the team chooses from when a deposit was never ours to post. Six to begin with: merchant/card settlement, patient payment, refund from a payer, interest or bank credit, transfer between accounts, and Other.

Order sets where each one sits in the picker. Note required makes the team say what it was — tick it for anything that means nothing on its own, which is why Other has it. Add your own: a list people cannot find themselves in becomes “Other” for everything, and then it tells you nothing.

Retiring is not deleting. A deposit stores the reason as text, so retiring a label takes it out of the picker and leaves every deposit already marked with it untouched. Renaming one changes what people pick from here on and deliberately does not restate decisions already made — somebody chose those words on the day. The In use count shows how many rows are holding each label now.

Settings

Thresholds the team tunes. Today that is how long a remit waits for its deposit before the queue calls it out — three days to begin with. It lives here rather than in the deployment so changing it does not need a developer.

Access log

Who did what, and when — reads as well as writes, one entry per request rather than per record. Nothing in it is ever deleted, including by the actions that delete other things: that a record was removed, and by whom, is exactly what a deletion must not erase.

Filter by search, date window, what happened, client, or person. What happened → Patient information isolates every EOB opened, uploaded or removed, which is the question a HIPAA accounting request actually asks.

One caution: an attachment filename is chosen by whoever uploaded it, and it is recorded in the detail column. A file named after a patient puts that name in this log. Treat the screen as Tier 1 and think before exporting it.

Clearing trial data

While a client is being tried out people will enter invented deposits. Clear all deposits on the client page removes every one of them, their attachments and every bank file that practice has sent, keeping the client and its people. One client at a time, named on the button, and you type the client code to confirm.

This is on its way out. It existed for the trial; the application now carries a live pilot, and a wipe button sitting on a production screen is a bad thing to leave lying around. It goes as soon as the last of the trial data is out.

Taking a client off the list

Archive is for a practice you are finished with: it leaves the day-to-day lists and everything is kept — deposits, attachments, history, people. One click puts it back.

Delete is only offered when a client has no deposits and no users, and you have to type the code. Once anything is attached, deleting is not offered at all: that history is the record this application exists to keep.

What this does not catch

Three things, and it is better to know them than to be surprised.

A deposit nobody reports is invisible. There is no row, so there is no variance — both sides are missing. The register is only as complete as what gets reported.

A remit that never arrives surfaces nowhere. The application does not read remittances from the clearinghouse or the practice management system, so if a payer transmits one and it does not land, nothing here will tell you.

A part-finished split reads short on the daily close and on the practice’s cash-reconciliation dashboard. Divide a 10,000 credit and allocate 9,500 of it, and those two screens report 9,500 of banking for the day — the unallocated 500 sits on the bank line, which is why that line stays in the queue saying so, and it appears on the practice’s own register under Still being matched. Finish the split and the figures agree again.

All three are known and accepted for this version, and they are why the reason list, the posting-lag number and the unallocated figure are worth watching.