Skip to content

Veona Bill

import { Steps } from ‘@astrojs/starlight/components’;

Veona Bill is the revenue surface. It turns the clinical work that happens elsewhere in Veona into money owed and money collected. Most charges are not typed in by hand — they auto-accrue from clinical events as they complete, then get assembled into an Invoice, optionally submitted to a payer as an insurance Claim, and reconciled against Payments and Remittance.

Key terms used on this page:

  • Charge — a single billable line raised by a clinical event (e.g. one lab test released, one drug dispensed). Charges start in the Open state.
  • Invoice — a grouped set of charges presented to a patient or payer for settlement. Supports multiple currencies and scheme (payer) pricing.
  • Claim — an invoice (or its covered lines) submitted to an HMO (Health Maintenance Organisation) or NHIS (National Health Insurance Scheme) payer for reimbursement.
  • Remittance — the payer’s response to claims: what they approved, rejected, and paid.
  • Credit Note — a formal reversal that reduces an issued invoice (eSign-PIN gated).

Roles below are the canonical billing roles (verified in apps/api/src/bill/bill.permissions.ts):

  • Cashier — collects payments, captures charges, takes deposits, builds estimates and statements, and takes installment payments. Read access to invoices. Does not create invoices or submit claims.
  • Billing Clerk — everything the cashier does for assembly plus creating invoices, submitting claims, requesting pre-authorisations and refunds, and creating payment plans.
  • Billing Manager — the full surface, including the privileged reversals: voiding an invoice, issuing a credit note, approving a refund, posting a claim, deciding a pre-authorisation, and managing billing config / payment gateway / settings. Privileged reversals (void, credit note) are eSign-PIN gated.

Administrator holds every billing key.

Veona Bill is included in the Health Centre, Hospital and Network editions. If a facility’s edition does not entitle the module, every /bill/* route returns 403.

The Veona Bill work surfaces (from apps/web/src/modules/bill/ModuleTabs.tsx):

Overview · Charge Capture · New Invoice · Cashier · Payments · Claims · Pre-Authorisation · Remittance · Deposits · Refunds · Receivables · Statements · Estimates · Payment Plans · Credit Notes · Service Hold · Tariffs · Payers · Capitation P&L · Reconciliation · Reports · Settings.

The Invoice detail and Claim detail screens are reached by clicking a row in their parent list (Overview / Claims), not from a standalone tab.

You rarely create charges by hand. As clinical events complete, Veona raises Open charges automatically through a central billable seam:

  • A lab result is released → a charge per test, priced from the lab catalogue.
  • An imaging report is signed → an imaging charge.
  • A prescription is dispensed → a charge for the drug × quantity.
  • A theatre procedure completes → surgery fee + consumables.
  • A ward bed-day accrues → daily rate × length of stay.
  • A patient is discharged → all Open charges are settled into one Invoice.

The Charge Capture screen is where you review these accrued charges and, when needed, add a manual charge for a billable event the system could not infer.

  1. Open Charge Capture (/bill/charges) and confirm the patient’s Open charges.
  2. Open New Invoice (/bill/invoice). Select the patient; their Open charges populate the invoice lines.
  3. Choose the currency and the applicable scheme (payer) so each line is priced against that scheme’s tariff. Tariffs are maintained on the Tariffs screen and payers on Payers.
  4. Review the line items — each carries the audit trail back to the clinical event that raised it.
  5. Issue the invoice. The patient’s balance rises; the invoice appears in Overview in the Unpaid state.

For a patient with HMO/NHIS coverage, the covered portion of an invoice is submitted to the payer.

  1. From the invoice (via Overview → row → detail) or the Claims screen, choose Create Claim.
  2. Select the payer scheme and the source invoice. The claim is created in the Draft state.
  3. Review the coverage percentage and covered lines.
  4. Submit to payer — the claim moves out of Draft and a FHIR Claim bundle is sent. (bill.claim.submit — Billing Clerk or Billing Manager.)
  5. The payer processes and responds; the claim’s state becomes Approved, Rejected, or Pending-Info.
  1. When the payer remits, open Remittance (/bill/remittance) to reconcile what was approved and paid against the submitted claims. Posting a remittance is a Billing Manager action (bill.claim.post).
  2. Patient-side collections (co-pays, cash, card) are taken on Payments (/bill/payments) or the Cashier desk (/bill/cashier). Each recorded payment decrements the invoice balance.
  3. Deposits (/bill/deposits) hold pre-paid amounts; Statements (/bill/statements) and Receivables (/bill/outstanding) track outstanding balances.
  1. A cashier or clerk requests a refund (bill.refund.request) from Refunds (/bill/refunds).
  2. A Billing Manager approves the refund (bill.refund.approve).
  3. To reverse part of an issued invoice, a Billing Manager issues a Credit Note (/bill/creditnotes). Both invoice void and credit-note issuance are eSign-PIN gated — you re-enter your 6-digit eSign PIN to confirm.

Payment methods, plans and pre-authorisation

Section titled “Payment methods, plans and pre-authorisation”
  • Payment Plans (/bill/plans) split a balance into installments; the cashier and clerk can take installment payments.
  • Pre-Authorisation (/bill/preauth) requests payer approval before a procedure; a Billing Manager decides incoming pre-auths.
  • Tariffs, Payers, Capitation P&L and Settings configure how prices, schemes and the payment gateway behave.