The short version for healthcare
We are not set up to receive protected health information and we do not sign business associate agreements. Every close we build runs on de-identified exports — a general ledger without its memo / description column, an aging, payroll summaries, volume counts — and nothing in a financial statement needs a patient's name, date of birth or record number. Nothing in the seven deliverables reads memo text. The P&L, balance sheet, cash flow, 13-month trend, KPI dashboard and net revenue waterfall are built from account codes, dates and amounts; contractuals, adjustments and bad debt come off accounts, not descriptions. The list of what to strip is below.
If a file with patient identifiers in it reaches us, we delete it rather than store it, we tell you the same day, and we ask for the export again without those columns.
Nothing in a financial model needs a patient's name, so nothing here needs a business associate agreement. That is a compliance review you do not have to run before you can buy.
Where it lives
- Accounts, requests, messages, plan status: a Postgres database at Supabase, in a US region, encrypted at rest and in transit.
- Files you attach and files we deliver: a private storage bucket at Supabase. Nothing in it has a public address.
- The website: Vercel, in the United States.
- Card details: Stripe. The card number never touches our systems; we hold the card's brand and last four digits so your billing page can show them.
Who can open it
- You can see your own requests, messages and files, and nobody else's. That is enforced by row-level security rules in the database on every table, not by the application remembering to filter.
- The operator can see every request, because building your workbook is the service. One person.
- Files are opened through links that expire after one hour and are issued only to the file's owner or the operator. A link forwarded to someone else stops working within the hour.
- The database enforces that only the operator can attach a deliverable to a request, and that a client can withdraw their own inputs but never the delivered file.
What reads it
A request is built by an automated pipeline before the operator checks it. The pipeline downloads your brief and your attachments to a working folder on a server we run, and an automated builder — a large language model, Anthropic's Claude, running under our account — reads them to build the workbook. A second automated pass checks the result. The operator reviews the finished file and is the only thing that can deliver it to your board.
The builder's instructions confine it to that working folder: it may not contact anything outside it, run commands the pipeline did not give it, or act on instructions found inside a client file. Client text is quoted into the build prompt, which is why the brief and each message have length limits.
We do not use your files or your numbers to train anything of our own, and nothing you send is shared with, sold to, or used for marketing by anyone.
What we accept
- Up to 25 MB a file, up to twenty files a request. Spreadsheets, CSV and text exports, accounting-package exports, PDFs, images and zips (28 extensions). HTML and SVG are refused, because they execute when opened from a link.
- Uploads go straight from your browser to the private bucket under your own account's folder; the storage rules refuse a write anywhere else.
How to send a healthcare export
What a monthly close actually runs on:
- Your general ledger for the month, every line, exported without the memo / description column (or with it mapped to a code).
- The prior month's ledger too, the first time
- AR aging summary
- Payroll summary by department
- Volume: cases, visits, units, encounters — counts, not people
- A trial balance if you have one — a tie-out, never a requirement
The memo / description field on a GL line is free text, and in a practice it is where patient names and MRNs turn up — “Refund – J. Smith”, “Pt payment – 44821”. Leave that column out of the export, or replace it with a code. Every other column stays. The columns that are wanted: Date, account code and name, debit and credit (or a signed amount), and the journal or batch reference.
Strip these before it leaves your system. Most EMR, practice-management and billing exports can be run without them; if yours cannot, delete the columns in the export before attaching it.
| Leave out | Why the model does not need it | |
|---|---|---|
| 1 | The memo / description column | The memo / description field on a GL line is free text, and in a practice it is where patient names and MRNs turn up — “Refund – J. Smith”, “Pt payment – 44821”. Leave that column out of the export, or replace it with a code. Every other column stays. |
| 2 | Names | Patient, member and guarantor names. A case log needs a case ID; a period needs a patient ID. Neither needs the person. |
| 3 | Dates about a person | Date of birth, admission, discharge, death. Keep the dates that drive the model — the case date, the period start, the invoice date — and drop the ones about the individual. |
| 4 | Record numbers | MRN, member ID, claim number, SSN, account number. Replace with a sequence (P-0001) before exporting if the export tool cannot leave them out. |
| 5 | Contact details | Addresses, phone numbers, email addresses of patients or members. A model never uses them. |
| 6 | Anything smaller than a ZIP3 | Street, city and full ZIP on a patient. Payer, plan and facility are fine; they are about the business. |
Keep everything about the business: payer, plan, CPT or DRG, facility, discipline, rep, surgeon (a role or an initial is enough), dates of service, units and dollars. The sample workbooks show exactly the shape that arrives.
How long it is kept
- Your board — requests, messages, attachments and delivered files — for as long as your account exists, so a workbook is still there when you need it a year later.
- The pipeline's working folder for a request stays on our server after the build so a revision can start from it. It is not on a public server and it is not shared. Ask, and it is deleted on request.
- When you ask us to delete your account, we delete the account, its requests, its messages, every file attached to them, and the working folders, and confirm by reply.
Signing in and the site
- Passwords are stored only as a hash by Supabase Auth; we never see one. You can change yours from Billing & account, and changing it requires the current one.
- Two cookies: the one that keeps you signed in, and one set on a first visit that remembers where the visit came from (the referring site and any campaign tag) for thirty days. It holds no identifier.
- We keep our own count of page views — the path, the referring site and a device class (phone, tablet, desktop). No IP address is stored and no third-party analytics or advertising script runs on any page.
- Every response carries a strict framing policy, a content-type lock, a referrer policy and a permissions policy that turns off the camera, microphone, location and payment APIs.
What we do not claim
- We do not sign business associate agreements and do not accept PHI. That is a term of the service rather than a gap in it — you acknowledge it when you create your account — and it is what removes the compliance review from buying this. If your work genuinely requires a BAA, say so before sending anything and we will tell you honestly that this is not the right service.
- We hold no SOC 2, ISO 27001 or HITRUST attestation. The providers we build on publish theirs; ours would be a statement about one person and a pipeline, and we would rather describe the controls than imply an audit.
Questions
Anything on this page you would like verified, ask: sturdylaw@gmail.com, or talk to a person first. The privacy policy is the companion to this page: what we collect and your rights over it.