Statement intake
A background service pulls statements from a shared mailbox and from FTP and SFTP drops, and routes each file to the right place.
Use case · Healthcare claims administration
Medical-scheme statements in a dozen layouts, read and reconciled in one place
CBOS built a platform that collects medical-scheme statements, reads each scheme’s layout, processes pharmacy claims and acknowledgements, and reconciles the lot against the bank, leaving staff to deal with the exceptions. It’s taking over the work of an ageing desktop system.
12+medical schemes whose statements it reads3ways statements arrive (email, FTP and SFTP), all picked up automatically
For teams paid by many funders, each with its own statement
Claims administratorsMedical billing bureausPharmacy group finance teamsPractice managersCommission and rebate teamsAnyone reconciling many payers against one bank account
The problem
A month of reading statements before you can match a single rand
Claims administration means matching three things: what was claimed, what each medical scheme says it paid, and what landed in the bank. Every scheme sends its statement in its own layout, as a PDF, a CSV or a spreadsheet, by email or file transfer. Without a system that reads them, someone opens each one, types in the figures and chases the differences by hand.
Statements in three places
They land in a shared mailbox, on an FTP server and on an SFTP server. Someone logs in to each one, downloads and files them, and a file that’s missed is a payment nobody checks until a client asks.
A layout for every scheme
Each scheme puts the reference, the amount and the date somewhere different. The person who knows all the layouts becomes the bottleneck, and month-end waits when they’re on leave.
Figures typed off PDFs
Every line is keyed in by hand. One swapped digit, R 4 310 typed as R 4 130, turns into a difference someone spends an afternoon tracing weeks later.
One payment, many statements
A scheme pays one amount that covers several statements. Splitting it across claims in a spreadsheet is slow, and it’s where the errors creep in.
Renewals in someone’s inbox
Practice-number renewals, rejected debit orders and proof of payment are tracked by hand. When one slips, the fix is a run of individual emails.
An old desktop app
The core of the job runs on a desktop application only one or two people can change, so every new format or rule waits for them.
Every rand has to be read off a statement before it can be matched, and right now people are doing the reading.
Before and after
From reading statements to handling the exceptions
Flip the switch to see the same month with the platform in place.
BeforeWith the system
- Someone logs in to the mailbox and file servers to download statementsStatements picked up from email, FTP and SFTP on a schedule
- Each scheme’s layout read and typed in by handA parser per scheme reads its PDF, CSV or Excel statement into clean records
- The bank reconciliation rebuilt in a spreadsheet every monthBank statements reconciled against scheme payments in the system
- Payments that cover several statements split by handStatements that cover several payments matched in the system
- Corrections made in the spreadsheet and lost by next monthReviewers send corrections back into the process
- An ageing desktop application few people can changeA modern web application on .NET and Angular, still being extended
Statements from a dozen schemes, downloaded, retyped and matched by hand every month.
Read and matched by the platform, with your team on the exceptions.
How it works
Four steps from inbox to reconciled
Each step runs in the platform, and staff step in where it flags something. Click through each one.
01Collect
02Read
03Match
04Review and report
Step 01
Collect
A background service checks the shared mailbox and the FTP and SFTP drops on a schedule, picks up each new statement and routes it to the right place. Nobody logs in to download anything.
Step 02
Read
Each medical scheme has its own parser. It reads that scheme’s PDF, CSV or Excel layout and turns it into clean records, so the figures aren’t typed in by hand.
Step 03
Match
Scheme payments are matched against the bank statement, including statements that cover several payments at once. Lines that agree are ticked off and the ones that don’t are flagged.
Step 04
Review and report
Each flagged difference goes to a reviewer, and the correction goes back into the process. Weekly and client-summary reports run straight off the platform’s database.
What we built
Six parts, one platform
The parts that carry a claims administrator’s month, built as one platform.
Scheme parsers
A parser for each medical scheme’s statement format turns PDFs, CSVs and spreadsheets into clean records.
Claims and acknowledgements
The platform processes pharmacy claims and reads the acknowledgements that come back from the claims switches.
Bank and statement reconciliation
Bank statements are matched against scheme payments, including statements that cover several payments at once, and reviewers send corrections back into the process.
Practice-number renewals
A renewals view tracks practice-number renewals, rejected debit orders and proof of payment, and sends bulk reminder emails.
Reporting
Weekly and client-summary reports run straight off the platform’s database.
Hover over a card for more.
What changes
What the month looks like for your team
Your team still owns the reconciliation. The platform takes the downloading, typing and matching off their desks.
Statements are already in
They’re picked up from email, FTP and SFTP on a schedule and filed by scheme before anyone starts.
Figures arrive captured
Each scheme’s parser reads the statement, so nobody keys in amounts off a PDF.
One reconciliation, shared
The bank reconciliation lives in the system, where the whole team can see it and work on it.
Time goes on the exceptions
Staff work through the lines the platform flags, and their corrections go back into the process.
Renewals in one view
Practice-number renewals, rejected debit orders and proof of payment sit together, with reminders sent in bulk.
A platform you can extend
A modern web application on .NET and Angular that’s still being extended, so a new scheme or rule doesn’t wait on one person.
Built with
The stack behind it
.NET 9C#Angular 18SQL ServerSSRSMicrosoft Graph (Office 365 mail)FTP and SFTPAzure DevOps
Questions
What you’re probably asking
Click a question to open it.
Do we have to switch off our current system first?
No. This platform is taking over the old desktop system’s work in stages: the parts already moved run on the new platform while the rest are still being moved across. We’d plan yours the same way.
Every scheme sends a different layout. Can it cope?
That’s what it was built for. Each scheme has its own parser for its PDF, CSV or Excel statement, and it reads more than a dozen schemes today. A new layout means adding or updating that scheme’s parser.
What happens to the lines that don’t match?
They’re flagged for a reviewer, and the reviewer’s correction goes back into the process.
Statements reach us by email and on file servers. Does that change?
No. The platform picks them up where they already land, a shared Office 365 mailbox and FTP and SFTP drops, on a schedule.
Where would we start?
With a conversation about where your statements come from and how you match them today. Then a first release that takes one piece off your team’s plate, for example intake and reading, and we build out from there.
Quick check
Sound like your business?
Tick what sounds familiar.
You receive statements from many funders or partners, each in its own format.
Someone on your team spends days each month capturing figures from PDFs and spreadsheets.
Your reconciliations live in spreadsheets that only one or two people understand.
A core part of your operation still runs on an old desktop application.
You find out about payment differences weeks after they happen.
of 5 ticked
0 to 1 ticked
Your statement and reconciliation work sounds under control. If volumes grow or a new format arrives, we’re here.
2 to 3 ticked
Part of your month is going into reading and matching documents a system could handle. We can help you pick the piece worth automating first.
4 to 5 ticked
Talk it through with us
You’re carrying a lot of manual reconciliation on ageing tools. We’ve replaced that kind of setup before, so let’s talk about yours.
More case studies
All case studies Other businesses we’ve built for
Let's talk
Still typing statements into spreadsheets?
Tell us which funders send you statements and how you match them today, and we’ll show you what a platform like this would take.
Use case · Healthcare claims administration
Medical-scheme statements in a dozen layouts, read and reconciled in one place
CBOS built a platform that collects medical-scheme statements, reads each scheme’s layout, processes pharmacy claims and acknowledgements, and reconciles the lot against the bank, leaving staff to deal with the exceptions. It’s taking over the work of an ageing desktop system.
12+medical schemes whose statements it reads3ways statements arrive (email, FTP and SFTP), all picked up automatically
For teams paid by many funders, each with its own statement
Claims administratorsMedical billing bureausPharmacy group finance teamsPractice managersCommission and rebate teamsAnyone reconciling many payers against one bank account
The problem
A month of reading statements before you can match a single rand
Claims administration means matching three things: what was claimed, what each medical scheme says it paid, and what landed in the bank. Every scheme sends its statement in its own layout, as a PDF, a CSV or a spreadsheet, by email or file transfer. Without a system that reads them, someone opens each one, types in the figures and chases the differences by hand.
Statements in three places
They land in a shared mailbox, on an FTP server and on an SFTP server. Someone logs in to each one, downloads and files them, and a file that’s missed is a payment nobody checks until a client asks.
A layout for every scheme
Each scheme puts the reference, the amount and the date somewhere different. The person who knows all the layouts becomes the bottleneck, and month-end waits when they’re on leave.
Figures typed off PDFs
Every line is keyed in by hand. One swapped digit, R 4 310 typed as R 4 130, turns into a difference someone spends an afternoon tracing weeks later.
One payment, many statements
A scheme pays one amount that covers several statements. Splitting it across claims in a spreadsheet is slow, and it’s where the errors creep in.
Renewals in someone’s inbox
Practice-number renewals, rejected debit orders and proof of payment are tracked by hand. When one slips, the fix is a run of individual emails.
An old desktop app
The core of the job runs on a desktop application only one or two people can change, so every new format or rule waits for them.
Every rand has to be read off a statement before it can be matched, and right now people are doing the reading.
Before and after
From reading statements to handling the exceptions
Flip the switch to see the same month with the platform in place.
BeforeWith the system
- Someone logs in to the mailbox and file servers to download statementsStatements picked up from email, FTP and SFTP on a schedule
- Each scheme’s layout read and typed in by handA parser per scheme reads its PDF, CSV or Excel statement into clean records
- The bank reconciliation rebuilt in a spreadsheet every monthBank statements reconciled against scheme payments in the system
- Payments that cover several statements split by handStatements that cover several payments matched in the system
- Corrections made in the spreadsheet and lost by next monthReviewers send corrections back into the process
- An ageing desktop application few people can changeA modern web application on .NET and Angular, still being extended
Statements from a dozen schemes, downloaded, retyped and matched by hand every month.
Read and matched by the platform, with your team on the exceptions.
How it works
Four steps from inbox to reconciled
Each step runs in the platform, and staff step in where it flags something. Click through each one.
01Collect
02Read
03Match
04Review and report
Step 01
Collect
A background service checks the shared mailbox and the FTP and SFTP drops on a schedule, picks up each new statement and routes it to the right place. Nobody logs in to download anything.
Step 02
Read
Each medical scheme has its own parser. It reads that scheme’s PDF, CSV or Excel layout and turns it into clean records, so the figures aren’t typed in by hand.
Step 03
Match
Scheme payments are matched against the bank statement, including statements that cover several payments at once. Lines that agree are ticked off and the ones that don’t are flagged.
Step 04
Review and report
Each flagged difference goes to a reviewer, and the correction goes back into the process. Weekly and client-summary reports run straight off the platform’s database.
What we built
Six parts, one platform
The parts that carry a claims administrator’s month, built as one platform.
Statement intake
A background service pulls statements from a shared mailbox and from FTP and SFTP drops, and routes each file to the right place.
Scheme parsers
A parser for each medical scheme’s statement format turns PDFs, CSVs and spreadsheets into clean records.
Claims and acknowledgements
The platform processes pharmacy claims and reads the acknowledgements that come back from the claims switches.
Bank and statement reconciliation
Bank statements are matched against scheme payments, including statements that cover several payments at once, and reviewers send corrections back into the process.
Practice-number renewals
A renewals view tracks practice-number renewals, rejected debit orders and proof of payment, and sends bulk reminder emails.
Reporting
Weekly and client-summary reports run straight off the platform’s database.
Hover over a card for more.
What changes
What the month looks like for your team
Your team still owns the reconciliation. The platform takes the downloading, typing and matching off their desks.
Statements are already in
They’re picked up from email, FTP and SFTP on a schedule and filed by scheme before anyone starts.
Figures arrive captured
Each scheme’s parser reads the statement, so nobody keys in amounts off a PDF.
One reconciliation, shared
The bank reconciliation lives in the system, where the whole team can see it and work on it.
Time goes on the exceptions
Staff work through the lines the platform flags, and their corrections go back into the process.
Renewals in one view
Practice-number renewals, rejected debit orders and proof of payment sit together, with reminders sent in bulk.
A platform you can extend
A modern web application on .NET and Angular that’s still being extended, so a new scheme or rule doesn’t wait on one person.
Built with
The stack behind it
.NET 9C#Angular 18SQL ServerSSRSMicrosoft Graph (Office 365 mail)FTP and SFTPAzure DevOps
Questions
What you’re probably asking
Click a question to open it.
Do we have to switch off our current system first?
No. This platform is taking over the old desktop system’s work in stages: the parts already moved run on the new platform while the rest are still being moved across. We’d plan yours the same way.
Every scheme sends a different layout. Can it cope?
That’s what it was built for. Each scheme has its own parser for its PDF, CSV or Excel statement, and it reads more than a dozen schemes today. A new layout means adding or updating that scheme’s parser.
What happens to the lines that don’t match?
They’re flagged for a reviewer, and the reviewer’s correction goes back into the process.
Statements reach us by email and on file servers. Does that change?
No. The platform picks them up where they already land, a shared Office 365 mailbox and FTP and SFTP drops, on a schedule.
Where would we start?
With a conversation about where your statements come from and how you match them today. Then a first release that takes one piece off your team’s plate, for example intake and reading, and we build out from there.
Quick check
Sound like your business?
Tick what sounds familiar.
You receive statements from many funders or partners, each in its own format.
Someone on your team spends days each month capturing figures from PDFs and spreadsheets.
Your reconciliations live in spreadsheets that only one or two people understand.
A core part of your operation still runs on an old desktop application.
You find out about payment differences weeks after they happen.
of 5 ticked
0 to 1 ticked
Your statement and reconciliation work sounds under control. If volumes grow or a new format arrives, we’re here.
2 to 3 ticked
Part of your month is going into reading and matching documents a system could handle. We can help you pick the piece worth automating first.
4 to 5 ticked
Talk it through with us
You’re carrying a lot of manual reconciliation on ageing tools. We’ve replaced that kind of setup before, so let’s talk about yours.
More case studies
All case studies Other businesses we’ve built for
Let's talk
Still typing statements into spreadsheets?
Tell us which funders send you statements and how you match them today, and we’ll show you what a platform like this would take.
Let's Connect
Interested in building a smarter, more connected operation? Contact us to discuss how AI can support your business goals.