Every figure carries the rule that produced it
Billing Module
The Eruntar Billing Module is patient billing and the revenue cycle for hospitals and clinics: charge capture, pricing and tax, who pays, insurance and claims, payments, receivables, cash custody, the ledger and period close.
It never rewrites history. A mistake is corrected by an adjustment, what is owed is derived from the movements, and the books close by checklist.
6
ways a service can be counted
5
kinds of payer worked out for every charge
17
automated checks before a period can close
28
conflicting duty pairs that need two people
Billing Module
Solutions
Who it is for
Hospital and clinic billing desks and finance teams
Charges
Entered at the desk from day one, or captured from events
Counted
Six ways, from per item to per night
Every figure
Priced, discounted and taxed by one engine, working shown
Who pays
Patient, insurer, corporate, government or other
What is owed
Derived from movements, never read back from a balance
History
Corrected by adjustment, never edited
A period
Six states, four locks, seventeen checks to close
Two people
Refunds, write-offs, overrides and reopened periods
Works in
Any browser, nothing to install
Entered at the desk from day one, or captured from a billable event. When something becomes a charge is a policy row rather than code, and automatic capture starts switched off.
Versioned price books, resolved at the date of service. An ambiguous match is an error, and missing tax configuration is an error rather than zero tax.
The responsibility engine splits the charge between patient, insurer, corporate and government payers before the invoice exists.
Processing, settlement and allocation are separate facts, so received is never confused with banked.
Reconciled against the provider and the bank, posted to the ledger, and closed by checklist.
The module, screen by screen
Receivables, the ledger, cash custody, period close, separation of duties and the audit trail, as a finance team sees them day to day.
The dashboard derives the position from the movements: the total owed, what is past due, and the aging buckets the organisation configured. Run it for a past date and it reproduces that day exactly.
The books
Receivables are split by who owes them: patient, insurance and corporate each have their own account, and deposits and patient balances sit on the liability side. Accounts hold no balance of their own, so the ledger is the only place a number can come from.
The rules
Each ledger role, such as cash in transit or bank fees, posts to an account under the dimensions you choose, from a date. A posting never invents an account, and you can ask the engine where one would land before you rely on it.
The finance floor
That is the module's own positioning. These are the places where the code enforces it, and where a busy month-end cannot become a restatement.
Refunds, write-offs, responsibility overrides, closing exceptions, keyed journal entries, reopened periods and cash differences. The database refuses it, not only the screen, and no setting lifts it.
The charge stops with a named error. It is never priced at zero tax because nobody said what the tax was.
Price resolution follows the configured strategy, and an ambiguous match is surfaced as an error for a person to settle.
Card numbers, security codes and track data are never stored, and free text that looks like a card number is refused.
A future period takes nothing until it is opened, and a closed one takes nothing at all. Both are the backend's decision, not the screen's.
Each event is hashed as it is written and sealed into a checkpoint that chains to the one before. Editing breaks its own hash, rehashing breaks the checkpoint, and rebuilding the checkpoint breaks the chain.
There is no receivable table. What is owed is derived from the movements each time, and a report for a past date reproduces that day exactly.
It is read-only by construction. A test in the build asserts that it cannot write, so a violation fails the build rather than a review meeting.
And once a charge is posted
A mistake is fixed by an adjustment row beside the original. The original stays exactly as it was written, and the adjustment says who made it and why.
Every price carries the calculation version and the trace that produced it, so why this figure has an answer long after the person who knew has moved on.
Ask what was owed on any past date and the report reproduces that day exactly, whatever has been paid since.
The intelligence layer is deliberately not a model today. It computes from the records, shows its working, and says so on screen. We would rather ship a layer we can defend than a claim we cannot.
They watch Billing's own records for leakage, denial patterns and payment risk. Each is computed from the records with its working shown, and none needs a model.
It resolves a question to a known one and answers it with the same code a screen uses. It works with no language model at all, and says so on screen.
The layer cannot write a financial table, and a test in the build fails if it ever tries. Where there is no history to project from, it projects nothing rather than inventing a figure.
Questions
It is patient billing and the revenue cycle for hospitals and clinics, built as one system from the charge to the closed books: capturing charges, pricing and taxing them, working out who pays, handling insurance and claims, taking payments, working receivables, holding cash, posting to a ledger and closing periods. The aim is that every figure has a reason and every reason is on the record.
By one calculation engine. The price is resolved from versioned price books at the date of service, an ambiguous match is an error rather than a guess, and a missing tax configuration stops the charge instead of quietly charging nothing. Every calculation keeps its version and a trace, so the working can be shown long afterwards. A discount above the configured tier needs a second person to approve it. India GST is supported, with CGST, SGST and IGST decided by place of supply; other regimes such as VAT are not available yet.
A responsibility engine works out the share for each kind of payer, patient, insurance, corporate, government or other, with packages as a layer on top, before the invoice exists. The billing desk shows the result per charge. An override of that result needs a second person to approve it, and the invoice then carries the patient, insurance and corporate shares side by side.
It records and tracks the whole insurance journey: versioned plans and benefit rules with a simulator, eligibility checks, authorisations with amendments and renewals, claims, adjudication, denials, appeals and the payer's remittance. A FHIR R4 eligibility and claim adapter exists and stays dormant until a payer endpoint and credential are configured. Payer-specific exchanges such as X12 or national networks are not available yet, so today the module is where the claim lives and is worked, not a live line into your insurer.
Not yet. Payments are recorded against the methods your organisation enables, such as cash, card, bank transfer, cheque and insurance settlement, and each payment keeps its processing, settlement, allocation and approval states as separate facts. Payment links, online checkout and 3-D Secure are not built, and no live payment gateway has been certified. Card numbers, security codes and track data are never stored, and free text that looks like a card number is rejected.
There is no stored receivable. What is owed is derived from the movements each time it is asked for, and the report for a past date reproduces that day exactly. Aging buckets are the organisation's own. Collection cases, promises, payment plans, disputes and write-offs are worked on one screen, and a write-off is requested, approved and executed by different people. A versioned dunning policy with quiet hours drives the work queue. Reminders and statements are queued and shown on screen; delivery by email, SMS or a patient portal is not built yet.
What was paid, what the provider settled and what the bank credited are shown side by side, and a difference is never an edit to a payment: it is something a person explains. Bank statements come in as CSV files, a file is identified by its content so the same file cannot settle twice, and the matching rules are versioned and can be run again to reproduce a result. Other statement formats and live bank feeds are not available yet.
Yes, as an opt-in per branch: a branch with no drawers behaves exactly as it did before. Drawers belong to collection points, cashiers work in sessions, counts are blind, cash handed between two people is shown as in transit rather than lost, and bank deposits close the loop. The expected balance is derived from the movements, never typed in, and a cash difference has to be decided by a second person.
A period moves through six states and carries four separate locks: ordinary billing, accounting entries, tax entries and reporting. Closing runs a checklist of seventeen automated checks, including that the trial balance balances, no journal is waiting, the subledgers agree with the ledger and the cash differences are decided. A required check blocks the close, a warning needs acknowledging, and the checklist is copied when a close starts so later edits never change a close that already happened. A closed period takes nothing at all.
Three ways, each enforced by the database rather than by good behaviour. History is not edited: a mistake is corrected by an adjustment row beside the original. Every audit event is hashed as it is written and sealed into a checkpoint that chains to the one before, so an edit breaks the chain and verification is a button. And tenant isolation is enforced on every table, with access to the module re-proven on each request and failing closed.
Some of this module deliberately needs two people. Refunds, write-offs, responsibility overrides, closing exceptions, keyed journal entries, reopened periods and cash differences are all refused when the same person tries to do both halves, by the database and not only by the screen, and no setting lifts that. A deployment with one user therefore cannot complete those workflows at all. It is a decision to make before you start, not a surprise after.
It is deterministic today. Twelve detectors watch Billing's own records for things like leakage, denial patterns and payment risk, and each one is computed from the records with its working shown. The assistant resolves a question to one of a fixed list of known questions and answers it with the same code a screen uses, so it works with no language model at all and says so on screen. Revenue leakage covers only what Billing can prove from its own records. The layer cannot write to any financial table, and a test in the build asserts that.
Yes. It has a currency master, an exchange-rate policy, legal entities with effective-dated branches, several tax registrations and country profiles that must pass activation checks before a country is switched on. Exchange rates are entered manually; there is no rate feed. Payments across currencies, three-decimal currencies and inter-branch consolidation are not available yet.
It is built for it. Clinical modules publish billable events under a versioned contract, other modules see only what they are allowed to of a patient's finances, and each has its own scoped credentials. The clinical modules do not yet send those events, so today charges enter at the billing desk. Automatic capture is also off by default: events that arrive while it is off are held, not lost and not billed.
It is built to support the controls those frameworks ask for, and it ships with a control matrix covering ISO/IEC 27001, SOC 1 and SOC 2, HIPAA, GDPR, PCI-DSS, PSD2 strong customer authentication, CCPA and CSA STAR. We do not describe the module as certified against any of them. Certification is something an organisation earns, and the matrix is there to make that audit shorter.
As a single Enterprise plan, quoted for your organisation by the branches and legal entities you bill from. Nothing is held back for a higher tier because there is no higher tier. Onboarding support comes with it, along with a direct line to the team building the module.
What is included
The Billing Module is sold as a single Enterprise plan, quoted for your organisation. There is no ladder to climb, so every capability on this page is included. Pricing is quoted for the branches and legal entities you bill from.
Branches & entities per agreement
Quoted for the number of branches and legal entities you bill from.
Talk to usNeed help choosing, or have a multi-entity structure? Talk to our team.
A working session rather than a slide deck: a charge priced and taxed with its working shown, a bill split between the patient and the insurer, a payment reconciled against the bank, and a period closed by checklist. Tell us how your billing desk is staffed and we will set one up. You get onboarding support and a direct line to the team building it.
Running the front desk as well? Explore the Reception Module.