How it works
How Auxilium works
You supply the roster you already have, the money in and out, the guidelines you already publish, and the claims as they arrive. Nothing else is data entry — the ratio, the findings, the escalations and the board all derive from those four.
Open the demo See every feature
- No card to open the demo
- Import a spreadsheet, export it back out
- Nothing is written until you approve it
members-export-final(2).csv
412 rows · 11 of 11 columns matched automatically
Nothing is written until you commit. A blank cell means “not provided”, never “delete what you know”.
What the first week actually looks like
No implementation project and no configuration phase. Each step is useful on its own, so stopping after any of them still leaves you better off than the morning before.
-
1
Day one — import the roster
Upload the export you already have, however messy. Column names are inferred from an alias table, so "Mbr #" and "Last, First" land where they should. Every row is validated and duplicates are matched against people already on file. The triage board is populated the moment you commit — most ministries find somebody they had lost track of that same afternoon.
-
2
Week one — record the ledger
Contributions in, disbursements out, each categorised. Connect Stripe and settled contributions record themselves; anything paid by cheque or bank transfer is entered once. This is the step that makes the share ratio a fact rather than a belief.
-
3
Week one — publish the guidelines
Your sharing guidelines, versioned and dated, each provision declaring which denial reasons it authorises. Roughly an afternoon of typing, once. From then on every decline is checked against the document that was actually in force on the day.
-
4
From then on — work the desk
Claims arrive with the fields a reviewer needs or they do not arrive at all. Each gets a due date at submission. The escalation desk shows what is late and what nobody has opened, and the integrity report recomputes itself as the ledger moves.
The ledger
One number you will be asked for, and can answer
Contributions and disbursements sit on one timeline, and every disbursement carries a category that decides which side of the ratio it lands on. That is all the share ratio is: of every dollar members contributed, how many cents reached their medical costs.
It is measured against the ACA medical-loss floor of 80.0% — which health care sharing ministries are not held to. That is precisely why it is worth measuring against: clearing a bar you are not held to says something no marketing page can.
- Related-party payments are broken out separately, because that is where diversion hides
- A month with money in and nothing out is the loudest signal the system produces
- Publish it on your own site, opt-in, with no member data in it
Share ratio, trailing 12 months
Of every dollar members contributed, what reached medical costs
Health care sharing ministries are not held to this floor. Clearing a bar you are not held to is the point.
Rules that can check themselves
A guideline version is not a PDF in a folder. Each provision declares the denial reason codes it actually authorises, which is what turns "we followed our guidelines" from a claim into something checkable.
That one field is load-bearing, because the signature pattern of this category is marketing "covered from day one" and then declining on precisely that basis.
What a provision declares
Illustrative rows in the shape the guideline table actually stores. The third column is the one that does the work: a decline citing a provision that does not authorise the stated reason is a finding, the week it happens rather than in a deposition.
| Provision | What it says | Denial reasons it authorises |
|---|---|---|
| 3.1 | Twelve-month waiting period for pre-existing conditions | pre_existing, waiting_period |
| 3.4 | Conditions treated in the 24 months before joining are pre-existing | pre_existing |
| 5.2 | Annual sharing limit per member | annual_limit_reached |
| 7.1 | Elective and cosmetic procedures are not shared | not_eligible_service |
| 9.3 | Bills must be submitted within six months of the date of service | late_submission |
A decline recorded against provision 5.2 for a pre-existing condition does not hold up, and Auxilium says so at the moment it is recorded — not blocking it, because blocking pushes staff to pick whatever provision the form accepts, which destroys the record rather than correcting it.
Which version binds a member is a decision the ministry declares, not one we assume: enrolment, date of service, submission, or when the bills were received. All four are in real use, and scoring the naive version would raise a serious finding against a ministry every time it followed its own published policy correctly.
Correcting a version that never matched the real document re-checks the decisions made under it, with the previous text kept on file. Publishing a genuinely new version does not — both documents are real, and each governed a period. A missing anchor date is never a finding at all: cannot-tell must not become an accusation built out of a gap in the data.
The claims desk
A claim that cannot quietly stall
Intake refuses what cannot be worked — a missing procedure code, a provider NPI that fails its check digit, no itemised bill — rather than accepting it into a queue where it will sit for months looking like progress.
Every accepted claim gets a due date from the turnaround your ministry chose. The clock pauses while you are genuinely waiting on the member, and a claim nobody has opened escalates before its deadline: the member cannot tell "being worked" from "lost", and assumes the first until it is too late to assume anything.
- Members see the same tracker your staff do, worded from the same computation
- Reference-based repricing against Medicare rates, with the basis recorded
- Eligibility answered before the procedure, never promissory
Claim #need_8fk2
Mercy General · outpatient procedure · $14,280 billed
- Submitted Mar 4
- Acknowledged Mar 5
- In review Mar 9
- Shared due Mar 21
Every proposal records its basis, so it reads as a negotiation rather than a refusal to pay.
The board
Who to call this morning, and why
Every member carries four readings — care, case weight, household complexity, and whether you are still in touch. A score is the sum of the weights of every rule that matched, and the reasons are always shown beside the number.
There is no model and no learned coefficient anywhere in it. A staff member who distrusts a score can add it up by hand and either agree or point at the rule they disagree with — and a system nobody can argue with does not get trusted with pastoral care.
- Ties break toward the hurting person, not the expensive case
- Equal scores are still a total order, so nobody loses their place in the queue
- The row shows its basis — "4 reasons · last contact 31 days ago"
Who needs attention today
4 of 128 members · ranked by band, then by direction
Hospitalization logged · no contact in 21 days
Claim past its 17-day due date · never acknowledged
7 people in the household · new dependent added
Two outreach attempts unanswered · renewal in 38 days
And what one member looks like up close
Grace Okonkwo
Okonkwo household · primary contact
Someone is hurting
The case has stalled
Household complexity
Still in touch
Why 88, exactly
- +40 Hospitalization logged in the last 30 days
- +30 No contact recorded in 21 days
- +18 Open prayer request past its follow-up date
A score is the sum of the rules that matched. Add it up yourself.
Four readings, each with the rules that produced it and the weight each rule carried. A member can carry several at once, and that is the point: high case weight with low care is a billing problem, and high on both is a family in crisis.
What is true by when
Assuming an afternoon of attention on the first day and an hour or two a week after that. Nothing here waits on us.
| By | What you have |
|---|---|
| The first afternoon | Your whole roster in, duplicates flagged, and a triage board ranking who needs contact first. |
| The first week | A share ratio computed from your own ledger, and a denial audit over the declines you have already recorded. |
| The first month | Every open claim on a clock, an escalation desk of what is late, and a public page you can point a member or a journalist at. |
| The first quarter | A trend rather than a snapshot: whether the ministry is getting better at follow-up, and whether the ratio is drifting. |
The order matters. The roster is useful before the ledger exists, and the ledger is useful before the guidelines are typed — so there is no point at which you have done half the work and have nothing to show for it.
The questions ministries actually ask
Our spreadsheet is a mess. Does that matter?
No, and it is the case the importer was built for. Mixed date formats, embedded newlines, a byte-order mark, ragged rows, the same family exported twice, "Mbr #" as a column name. Only a row with no name at all is refused — everything else imports with a warning attached, because refusing a family over a typo’d postcode is worse than importing them and flagging it.
Do we have to stop using what we have?
No. Auxilium reads the roster and ledger you already keep and exports back out, so it can run alongside a CRM or an administration platform indefinitely. Plenty of ministries should keep both — the relationships and the giving history stay where they are, and the sharing workflow moves.
Our guidelines are not written down that precisely.
Then that is the finding, and it is worth having on day one rather than in a complaint. A ministry recording declines against no published guidelines is generating findings against itself, so the setup checklist names it and says what breaks while it is undone. Most of the work is transcription rather than decision.
What happens to members while we switch?
Nothing they need to act on. Stored cards and verified bank mandates transfer processor to processor with no member involvement, and billing dates are preserved so nobody is charged twice or skipped. The churn ministries fear when switching is almost entirely self-inflicted, and it comes from sending everybody an email asking them to re-enter their payment details.
Who can see a member’s medical circumstances?
Staff at that ministry, and the member themselves. Member accounts live in a different table behind a different cookie from staff accounts, so a member session cannot satisfy a staff check — not because a query remembered to compare a role, but because the lookup goes somewhere else entirely.
How long before we know whether it is working?
One afternoon. The demo ministry is seeded with five families each carrying a different kind of trouble and a full integrity report with real findings, so you can judge the product before importing anything of your own.
What it runs on
Cloudflare Workers, with D1 for records, R2 for documents and queues for background work. Practically: it is fast from anywhere, there are no servers to maintain, and the records live in one auditable place rather than across four spreadsheets and an inbox.
Every mutation writes an audit row, money is stored in integer cents so a share amount cannot drift, and deletes are soft — so "why did this happen" is a question with an answer months later.
Open the demo and work the board
Five families, a full ledger, and an integrity report with findings you can argue with.