who submits fp17 claims? Is it the practice manager?
==The treating dentist or clinician== technically submits the FP17 claim, but the practice manager or administrative team typically handles the electronic transmission and reconciliation pipeline. [1, 2]
Because you are building an app, it is helpful to think of it as a two-stage process split between clinical execution and operational transmission:
The individual clinician is legally and contractually responsible for the clinical accuracy of the data. [3]
While the dentist creates and authorises the claim data, they rarely manage the actual data packets moving to the NHS.
When designing your Access Control Lists (ACL) and user roles, structure the workflows distinctly:
Would it be useful to look at the different validation states a claim should cycle through in your UI depending on whether a dentist or a practice manager is looking at it?
[1] https://nhsbsa-opendata.s3.eu-west-2.amazonaws.com
[5] https://docs.dentalplus.online
[6] https://docs.dentalplus.online
[7] https://help.softwareofexcellence.com
[8] https://aerona.zendesk.com
[9] https://help.softwareofexcellence.com
So the practice manager takes care of the financial side - submitting it to nhsbsa and raising an invoice for the amount?
==No, practices do not raise or send invoices to the NHS==. [1]
The NHS payment structure works via block grants and activity deduction, making it entirely different from typical B2B or private invoicing.
Instead of the practice manager invoicing the NHS, the financial flow is fully automated based on the electronic FP17 claims data:
Do not build an "Invoice Generator" module for NHS work. Instead, design a Reconciliation Ledger that handles the monthly DCS129 Statement Ingestion.
Every month, the NHSBSA publishes an electronic statement showing:
Your app should allow the manager to import this monthly file to cross-verify that the NHS's internal math matches the local database totals.
Would you like help designing the ledger database table that tracks these local patient collections against the expected NHS clawback deductions?
[3] https://questions-statements.parliament.uk
But how is a practice supposed to manage its accounts for the incoming revenue for fp17 claims then?
To manage incoming revenue accurately for FP17 claims, a dental practice relies on a process called ==Schedule Reconciliation== rather than standard invoicing.
In your app, the accounting side should not look like an invoice ledger. Instead, it must look like a Clearing Ledger that balances three distinct numbers: Expected Patient Revenue, Actual Patient Cash Collected, and the NHS Gross Schedule Payment.
Here is exactly how a practice manages its accounts for this revenue, and how your software should model it:
For NHS work, revenue lands in the practice accounts from two completely different directions for the exact same Course of Treatment (CoT):
Because the NHS deducts (claws back) the patient fees from their monthly block payment to the practice, the accounting logic for every completed FP17 must balance out to zero on a per-claim basis:
Your app needs an automated accounting workflow to replace the manual spreadsheet tracking most practice managers dread.
As dentists complete treatments, your system should automatically log two ledger entries for the day’s accounting:
On or around the 19th of every month, the NHSBSA releases the DCS129 Schedule file via Compass. This is the equivalent of a bank clearing statement. Your app must allow the practice manager to upload or API-fetch this file.
The software must parse this file to execute a three-way match:
┌─────────────────────────────┐
│ Your App's Claim Ledger │
│ (e.g., Claim ID #98721) │
└──────────────┬──────────────┘
│
┌───────────────────────┴───────────────────────┐
▼ ▼
[ Match 1: UDAs ] [ Match 2: Cash ]
Does NHSBSA credit the Did the NHSBSA clawback
same UDAs your app calculated? amount match the £26.80
(e.g., 3.0 UDAs for Band 2) collected at reception?
Once the practice manager clicks "Reconcile" on the monthly schedule inside your app, your software should generate a clean journal entry to push to their accounting tool via API.
The journal entry maps the complex NHS statement into standard business accounts:
| Account Name | Debit (£) | Credit (£) | Description |
|---|---|---|---|
| Bank Account | 18,500.00 | Actual cash received from NHSBSA | |
| NHS Patient Charge Clawback | 1,500.00 | Amount the NHS deducted because the practice already took it in cash at reception | |
| NHS Contract Income | 20,000.00 | The practice's baseline monthly NHS Gross entitlement |
To make your app indispensable to practice managers, you must build tools that catch when these accounts don't balance:
Would you like to see a draft database schema layout for this NHS Clearing Ledger Table, or should we look at how to calculate the performer pay splits based on these reconciled schedule figures?
Well we need this explained in more detail because I am quite confused how a dental clinic is supposed to manage and maintain its accounting - are you saying invoices should not be used at all?
It is completely understandable to find this confusing. The UK NHS dental system uses a unique framework that doesn't align with standard business invoicing.
To answer your question directly: Yes, for NHS treatments, standard invoices should not be used at all to request payment from the NHS.
If your software generates an invoice addressed to the NHS asking for "£5,000 for January's dental work," there is nowhere to send it, and no one will pay it.
Here is exactly how a clinic maintains its accounting books under this system, broken down into simple, practical steps.
A dental practice has to manage two distinct types of money. Your software needs to handle them differently:
To maintain clean, legally compliant accounting records (e.g., in Xero or QuickBooks), the practice manager records three specific transactions every month. This is how your app should automate it:
At the start of the month, the clinic receives a fixed bank transfer from the NHS (e.g., £20,000). In their accounting books, this is recorded as a simple deposit:
Throughout the month, patients pay their NHS Band charges at the desk (e.g., a patient pays £31.90 for a check-up).
The NHS expects the clinic to keep that £3,000 collected at reception. Because the clinic kept that cash, the NHS will deduct exactly £3,000 from the following month's payment.
To account for this, the practice manager uses the NHS Activity Schedule (the statement sent by the NHSBSA at month-end) to balance the books.
Instead of an "Invoices Module" for NHS work, your app needs an NHS Claims & Payments Ledger. It should match three numbers for every single Course of Treatment:
| The Action | What Your App Records | What Happens Internationally |
|---|---|---|
| 1. The Dentist Finishes Treatment | The app calculates the NHS Band (e.g., Band 1) and logs a pending claim. | No accounting movement yet. |
| 2. Reception Takes Payment | The app logs the cash/card payment from the patient. | Balances the patient's individual account to £0. |
| 3. Month-End Reconciliation | The app imports the NHSBSA file to verify the NHS accepted the claim and deducted the correct amount. | The claim status updates to "Settled & Reconciled". |
Does seeing the breakdown between the Patient Receipt and the NHS Monthly Schedule help clarify the database relationships you need to build, or would you like to see the exact accounting journal entries a clinic uses to log these figures at the end of the month?
yes please do show how to handle the Performer Pay / Associate Dentist Splits
To calculate pay splits for Associate Dentists (Performers) working under an NHS contract, your app must move away from standard revenue-commission logic.
In the UK, Associate dentists are self-employed contractors. They are typically paid a fixed rate per Unit of Dental Activity (UDA) that they successfully deliver and get credited for by the NHSBSA, rather than a percentage of the cash collected at reception.
Here is the exact framework you need to build into your app's Associate Pay & Performer Ledger Module.
When a practice manager hires an Associate, they agree on a specific Performer Schedule inside their contract. Your app's database must store these three mandatory fields for every dentist user profile:
The app should calculate the Associate's monthly net pay using the following sequence:
Critical Dev Rule: Never calculate an Associate’s monthly pay based on what treatments they marked complete in the chair. You must calculate pay based on what the NHSBSA formally accepted and processed on the monthly schedule file. If a claim bounces back with an error or is disallowed for being submitted too late, the practice doesn't get credited, and the Associate should not be paid for it until it is resolved.
Let’s trace a realistic monthly payroll calculation for an Associate, Dr. Sarah Patel, using data your app should automatically aggregate:
| Calculation Step | Logic | Amount (£) |
|---|---|---|
| Gross UDA Earnings | 400 UDAs × £12.50 | + £5,000.00 |
| Less: Lab Fee Deduction | £400.00 Total Lab Costs × 50% | - £200.00 |
| Less: Superannuation (Pension) | 9.3% of Gross Earnings (£5,000 × 0.093) | - £465.00 |
| Net Pay Owed to Associate | Gross (£5,000) - Lab (£200) - Pension (£465) | = £4,335.00 |
To make your Associate module seamless, the UI should provide an Associate Performance & Pay Statement that mimics the layout above. Behind the scenes, your database needs to link clinical items directly to lab costs.
┌─────────────────────────────────────────────────────────┐
│ Course of Treatment (CoT) │
│ Linked to Performer ID: 102 │
└────────────────────────────┬────────────────────────────┘
│
┌──────────────────────────┴──────────────────────────┐
▼ ▼
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
│ Clinical Payload │ │ Lab Work Order │
│ Tracks: UDAs (e.g., 12.0 UDAs) │ │ Tracks: Commercial Lab Invoice │
│ Status: Reconciled on Schedule │ │ Amount: £150.00 │
└─────────────────────────────────┘ └─────────────────────────────────┘
Type: Debit, Amount: £50, Reason: Retroactive UDA Claws-back) to keep the payroll accurate.With the client intake, payload schemas, practice ledger, and now performer payroll splits designed, your app's financial core is robustly mapped out.
Would you like to focus next on the front-end UI patterns for dentists to chart these treatments easily without data errors, or do you want to explore how to handle mixed NHS and Private treatments on the same patient file?
yes lets focus next on the front-end UI patterns for dentists as well as how to handle mixed NHS and Private treatments on the same patient file
To build a front-end clinical charting interface that dentists actually enjoy using, you must solve their biggest frustration: accidental clicks causing compliance errors.
Because NHS dental bands are legally binding data structures, a clumsy UI can lead to incorrect FP17 submissions, lost revenue, or NHS audits.
Here is the blueprint for designing the front-end UI patterns and the data architecture required to handle mixed NHS and private treatments seamlessly on a single patient record.
The clinical chart is where the dentist spends 90% of their time. It must be highly visual, quick to navigate via keyboard or mouse shortcuts, and guarded by smart validation boundaries.
Instead of forcing the dentist to choose an "NHS Mode" or a "Private Mode" for the entire patient file, your UI must support item-level routing.
The Scheme Selector Toggle: Every treatment item in your quick-pick sidebar (e.g., Composite Filling, Scale & Polish, Crown) should feature a subtle toggle or split button allowing the dentist to select the delivery scheme instantly.
Color-Coded Visual Anchors: Use distinct, universal color codes across the graphical tooth chart and the treatment ledger to make scheme segregation instantly scannable.
Do not let a dentist close a Course of Treatment (CoT) if it contains clinical data mismatches. Use contextual UI overlays to prompt for missing mandatory fields before the claim is finalized:
bpe_scores field. If it is null, display a non-intrusive sidebar prompt: "NHS compliance requires a Basic Periodontal Examination score before completing this CoT." [1]A massive percentage of UK dental activity is "mixed". For example, a patient may receive an NHS check-up (Band 1) and an NHS filling (Band 2), but request a high-end cosmetic private tooth-whitening treatment during the same cycle of care.
In your system backend, never bundle NHS data and private data into the same Treatment Plan entity. They must exist as two parallel tracks linked to a single "Master Episode" or "Appointment Cycle."
┌──────────────────────────────────┐
│ Master Treatment Cycle │
└────────────────┬─────────────────┘
│
┌────────────────────────────┴────────────────────────────┐
▼ ▼
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
│ NHS Course of Treatment │ │ Private Treatment Plan │
│ Tracks: Only NHS Schema Items │ │ Tracks: Cosmetic/Private Items │
│ Triggers: FP17 XML Generation │ │ Triggers: Direct Invoicing │
│ Patient Fee: Cap at Band Max │ │ Patient Fee: Itemised Pricing │
└─────────────────────────────────┘ └─────────────────────────────────┘
The Checkout Ledger Split: When the patient goes to the reception desk to pay, the system must display two distinct financial blocks on the screen:
Automating the FP17DC Layout: Under NHS regulations, if a patient receives private work alongside NHS work, the practice is legally required to hand them an FP17DC form. Your app should feature an automated "Print/Email Mixed Care Agreement" button that pulls data from both parallel tracks, explicitly showing what the NHS is covering and what the patient is paying for privately.
To give your front-end team a tangible starting point, here is a scannable wireframe layout for the primary clinical terminal window:
+------------------------------------------------------------------------------------+
| PATIENT: John Doe (DOB: 12-04-1988) | NHS STATUS: Standard Paying Patient |
+------------------------------------------------------------------------------------+
| [ GRAPHICAL TOOTH CHART VIEW - VISUAL REPRESENTATION OF MOUTH ] |
| - Upper Left 4: [ Filling 🔵 NHS ] |
| - Upper Right 1: [ Cosmetic Veneer 🟢 PVT ] |
+------------------------------------------------------------------------------------+
| CURRENT EPISODE LEDGER |
| |
| [🔵 NHS TRACK] Course of Treatment #55912 |
| - 12-Oct: Examination & Diagnostics (Band 1) ........................... Included|
| - 14-Oct: Amalgam Filling UL4 (Upgraded to Band 2) ..................... £73.50 |
| [ Status: Completed ] -> [ Core Clinical Metrics Filled: BPE 2,2,1,1,2 ] |
| |
| [🟢 PRIVATE TRACK] Cosmetic Plan #11204 |
| - 14-Oct: Porcelain Veneer UR1 ......................................... £450.00 |
| [ Status: In Progress ] |
+------------------------------------------------------------------------------------+
| RECEPTION CHECKOUT ESTIMATE SUMMARY |
| Total NHS Liability: £73.50 | Total Private Liability: £450.00 |
| Total Due from Patient: £523.50 ➔ [ Generate FP17DC Agreement Form ] |
+------------------------------------------------------------------------------------+
To finalize your app's core functional specifications, would you like to map out the automated text/email notification rules to remind patients about outstanding NHS band balances, or should we design the audit trail engine that tracks changes made to an FP17 after it has been signed by the clinician?