The 18 modules form the feature catalogue; they are not a mandatory selection. You decide which areas your institution uses. AI is activated only on request. Clinical dependencies and finalisation are described on the module pages.
01 / IN DAILY USE
Tasks and responsibility.
You choose this module according to your institution's needs. The interfaces described are configured for the areas you select. AI support is available exclusively on request and processes data on Oronela's own servers in Switzerland.
Operational billing connects contracts and valid tariff profiles with services actually confirmed. Each invoice line remains traceable to its stay, service record and the tariff used. Care, support, accommodation and additional services can thus come together in one verifiable billing process.
The latest specification includes Swiss funding body billing for the 2027 launch. It adds XML 5.0, separate insurance profiles, traceable allocation between funding bodies, indication codes for relevant medication and protected resident copies. The specific application is defined for each institution, canton, insurer and chosen transmission partner.
Confirmed quantity, unit, date, provider, source revision, fixed monetary values and immutable invoice revision.
Handover and correction
Dispatch order, original format, technical and professional response, linked correction and external payment status.
02 / MODULE FUNCTIONAL SCOPE
What this module covers.
4 functional areas connect this module's tasks. The following sections explain the content, handling and responsibilities.
01
Contracts, funding bodies and tariff profiles
Maintain master data once and reuse valid contract and tariff foundations throughout the billing process.
Residence contracts, contracting parties or representatives, service catalogues, funding shares, funding authorisations, currency and site or cantonal profiles have validity intervals and approved revisions.
Financial amounts are calculated using a suitable decimal or monetary representation; the profile defines rounding, sequence, units and temporal assignment. No binary floating-point billing.
Overlapping tariff rules, missing funding approvals and incomplete contract assignments are shown before approval or blocked according to the approved profile.
Retrospective changes do not overwrite foundations already used. The system shows affected open and already invoiced transactions and generates controlled correction tasks.
Confidential contract and financial data have their own actions and purposes; care staff see only the operational service information they need.
Responsibility
Administration maintains profiles, professionally authorised billing managers approve them, and representatives sign only permitted contract types; a technical administrator role does not authorise tariff approval.
Automation & AI
Rules identify gaps and expiries; local AI may structure contract documents into labelled drafts. Amounts, funding bodies and legally or professionally binding clauses require responsible review. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
02
Service evidence and invoicing
Transfer approved services into traceable invoice drafts without duplicate entry and handle exceptions precisely.
Importing services references the stay, service type, quantity, time, provider, originating module and approved source revision. Cancellation or correction of the source is processed separately.
The invoice run covers defined periods, checks missing evidence and prevents duplicate billing. The current working draft and professionally approved invoice are separate.
Allocation between funding bodies, approved tariffs, rounding and correction procedures are calculated deterministically from frozen foundations and supported by reference cases.
In addition to UUIDv7, invoice numbers are domain identifiers; their approved format, any gaps and cancellations remain traceable. They do not replace a technical primary ID.
Corrections create a referenced new invoice or credit note according to the profile; an amount already approved is never silently overwritten.
Responsibility
Billing staff process invoices and designated professional owners confirm disputed evidence; the resident portal receives only explicitly approved documents belonging to that resident.
Automation & AI
Rules collect services and flag deviations; AI explains an invoice in a traceable way or suggests queries. AI does not create services delivered or approve amounts. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
03
Finance and payroll handovers and responses
Controlled transfer to existing financial and payroll systems and clear handling of rejections without manual reconciliation spreadsheets.
Financial export packages carry the period, unique package and transaction IDs, profile and mapping revision, counts, checksums, monetary totals and source references. M11 owns only financial packages and their financial business statuses. M06-H owns the authoritative payroll snapshot, its period logic and professional approval; M17 owns transport. With appropriate HR authorisation, M11 shows only a read-only status projection of the payroll export with a source reference.
Scheduled, generated, transmitted, technically accepted, professionally accepted or rejected and externally paid are separate states; a missing response is shown as unknown.
An idempotency contract with each financial counterpart and manual clarification of uncertain delivery prevent blind resending as a new business transaction. Payroll retries and corrections are referred to the leading M06-H process; M11 does not create a second time snapshot of its own.
A domain-related rejection opens an actionable exception with responsible parties. Retransmission uses the same business transaction identity; corrected content receives an explicit successor revision.
Payment and payroll statuses are marked as external information with time and source. Portability and access to exported files are time-limited and audited.
Responsibility
Authorised billing and staff administration are separated by data type, with a narrowly scoped service account for the finance interface; financial approval and rejection handling are M11 actions, while payroll approval and correction take place exclusively in M06-H.
Automation & AI
Automatic technical retries follow partner rules, deadlines and reconciliation of totals. AI can explain rejection reasons but cannot confirm payment or invent payroll values. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
04
Resident contracts and complete contract execution
Contract execution binds the stay, agreed services, tariff attachments and actual signing authority.
A contract process references the existing contract revision from M11-A, the stay and the associated service and tariff schedules. Contracting parties, invoice recipients and information contacts are treated separately. Naming a contact person does not make them an authorised signatory representative.
The resident's wishes, required representation and appropriate form of agreement are responsibly checked. The system does not presume a lack of decision-making capacity. Where multiple care-home signatories are required, the agreement is complete only after the necessary signatures and their evidence are present.
Residents and authorised representatives see only the approved contract document and its associated attachments. An invitation does not provide general access to resident or personnel files. If representation is revoked before the final signature, the process requires clarification again.
New clauses or a changed tariff attachment require new content approval and the associated signing process. Dispatch confirmation, a received signature and an effective contract remain different states. Historical attachments and original evidence are preserved.
A paper agreement is maintained with a verified scan, signing information and storage of the original. A combination of paper and digital execution is supported only within an explicitly approved form profile and must fully evidence the same agreement.
Responsibility
Administration prepares; responsible professionals review content and representation; residents and authorised care-home signatories execute the agreement.
Automation & AI
AI explains approved content or flags missing evidence. Legally binding content and its acceptance are reviewed by a responsible person. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Contract execution and binding approvals take place online. The paper alternative remains fully supported as a separate evidence route.
03 / SWISS BILLING 2027
The new billing functionality in detail.
Swiss billing 2027: separate funding body profiles
The extension of 30 September 2026 adds to the scope of modules M03, M11, M12 and M17, which can be selected according to need. It does not introduce an additional nineteenth module. For a specific billing case, insurance area, funding body, service provider, location, tariff, coverage period and transmission partner are checked together.
KVG, IV and other commissioned insurance or funding areas have separate approved profiles. GLN, ZSR and external insurance or decision references are validated against their source. A valid identifier does not confirm coverage or grant access rights.
Care services, the resident's share and public residual funding are allocated according to effective site and cantonal rules. Missing assignments, unclear funding authorisation or an unapproved tariff block the affected case. The interface shows the specific cause and the responsible next review step.
generalInvoice XML 5.0 and versioned message families
For service invoices, generalInvoice 5.0 with Request and Response forms part of the latest billing specification. Schema, code lists, print layout, examples and the specific release edition are fixed in the partner profile. Validation checks both the technical structure and domain content before approval and dispatch.
The invoice standard is separate from the transport route. A syntactically valid XML file proves neither tariff validity nor insurer acceptance. Professional identity, date, quantities, codes and funding-body references are additionally checked against confirmed foundations.
Funding authorisations and needs notifications use their own message families. generalCredit and careCredit are handled with their respective approved version; changing invoices to 5.0 does not automatically change these processes. SHIP and Forum formats also need their own specific partner contracts.
CSS has accepted generalInvoice 5.0 since 1 January 2026 and specifies 30 June 2027 as the end date for new service invoices in XML 4.5. Later cancellations and reminders in 4.5 remain supported there only for invoices originally submitted in 4.5. This is a CSS partner rule; other counterparties have their own confirmed deadlines and version profiles.
From 1 January 2027, the Central Compensation Office requires electronic invoices from disability insurance service providers. Forum XML, a recognised data transmitter and the required decision or report reference are specified. This disability insurance profile is activated separately and checked with the chosen counterpart.
For relevant medications with a pricing or reimbursement model, the Federal Office of Public Health specifies transmission of the indication code on prescriptions and invoices from 1 July 2026. From 1 January 2027, insurers may reject invoices without a required code. The system takes the code from a confirmed professional source; the rule does not apply indiscriminately to every medication.
Profiles store the validity start, transition, original version and approved handling of successors. This does not imply that all Swiss invoices and messages must use the same format from the same date.
Exact monetary values, tariff intervals and verifiable approval
Monetary values are calculated using exact decimal representation. The approved tariff profile determines currency, unit, rounding mode and the time and order of rounding. A rounded individual line does not automatically make a correctly rounded total invoice.
A tariff change during a stay is split according to the service date. The tariff, contract and source revisions used are fixed in the approved invoice. A later tariff correction does not overwrite already approved amounts; it identifies the correction required for controlled processing.
Billing runs prevent the same confirmed service from being invoiced simultaneously on multiple invoices. Missing units, overlapping tariffs, conflicting coverage and subsequently revoked service evidence generate targeted review cases. Approval and dispatch require current permissions and an online check.
Dispatch, rejection, payment and correction
Draft, professional approval, dispatch order, technical acceptance, professional acceptance or rejection and externally confirmed payment are separate states. Transport evidence or a positive receipt acknowledgement does not mark the invoice as paid.
After a timeout, the partner may already have received the invoice. Its status therefore initially remains uncertain and is reconciled using the same transaction identity. Automatic retries follow the specifically agreed partner profile; they do not create a new invoice as a supposedly safe replacement transmission.
Responses are checked against sender, customer account, original invoice and revision. Duplicate or mixed-up responses must not cause a second posting or an unnoticed regression in status. Contradictions and unknown codes are passed to a responsible person for handling.
Corrections, cancellations and credit notes reference the original invoice. Original XML, the readable original representation, amounts, schema version and source evidence remain unchanged. Historical 4.5 follow-up processes are handled according to their confirmed partner profile and are not blindly converted into new 5.0 invoices.
Resident copies, consent and protected documents
The approved invoice receives a clear copy for the resident or the specifically authorised recipient. Its content and invoice revision are linked to the original. Contract language, recipient language and user interface language are handled separately.
The Federal Data Protection and Information Commissioner describes the obligation to provide invoice copies as applying to care homes too. Electronic transmission requires explicit consent and appropriate safeguards; a paper copy may be requested at no additional charge. The institution profile maintains the verified delivery choice and corresponding evidence.
M12 handles the protected document revision and explicit portal approval. Current representation and access rights are checked again on retrieval. Invoice data belongs neither in general email previews nor in unprotected transport logs. Retention, restrictions and later disclosure remain connected to M18.
Before production implementation, provider and location identifiers, actual tariff sources, funding body rules, canton profiles, rounding cases, resident copies and the selected transmission partner are professionally confirmed. Acceptance reviews use independently verified monetary amounts and real or approved partner test environments.
Legacy data retains the invoice number, original version, amount and existing dispatch evidence. Migration must neither assign new numbers to invoices already sent nor treat an unclear outcome as definitely not sent. A technical rollback does not undo a transmission that has already occurred.
Oronela manages the operational service chain and its invoices. General ledger, tax closing and net payroll calculation remain in the designated finance and payroll systems. Financial handovers originate in M11, approved payroll time foundations in M06; M17 is responsible for technical transport.
04 / PRACTICAL EXAMPLE
Monthly invoice with a tariff change and rejection
01
Confirmed services are assigned to valid tariff intervals according to their service dates.
02
Billing checks missing information, funding shares, references and rounding rules.
03
After approval, the original invoice and resident copy are created and passed on through approved routes.
04
A rejection opens a case for the responsible person to handle; any required correction references the original invoice.
The original invoice retains its amounts, sources and XML version. Technical receipt, professional acceptance and confirmed external payment receipt are managed separately.
SYSTEM WORKFLOW / Typical workflow
Typical workflow
01
A valid residence contract is linked to a funding body and time-dependent tariff.
02
Only approved services actually delivered form the invoice basis.
03
The invoice is created; sending, acceptance, rejection and financial status remain traceable.
View the domain workflow in 3D +
M11 / WORKFLOWCare
Contract & tariff basisBeing transferred
Illustrative workflow model
01Contract & tariff
→
INFORMATIONContract & tariff basis
→
02Approve service
Stay · Funding body · ValidityReady for handover
A valid residence contract is linked to a funding body and time-dependent tariff.
Contract, confirmed service and invoice form a continuous chain of evidence.What information is passed on?
01 → 02
Contract & tariff basis
Stay · Funding body · Validity
02 → 03
Approved services
Delivery · Period · Evidence
DATA EXCHANGE / MODULE CONNECTIONS
Interfaces in context.
M11 is at the centre. The connections show which modules can provide or receive information when selected and configured for your institution. Choose a connection to see its data scope.
M11 / CONNECTIONSExchange across modules
Stay contractBeing transferred
Versioned module contracts
M01Stay contract
→
INFORMATIONStay contract
→
M11This module
Stay, representation and funding body assignment.Ready for handover
Stay, representation and funding-body assignment. Valid contracts and tariffs are assigned according to time.
The connections show domain data relationships. Specific API contracts and partner connections are versioned and approved separately.
The domain invoice format and transmission partner are separate contracts.
The module requirements define the exchange of domain information. Each module manages its own data; other modules use approved, versioned contracts. Permissions, tenant, revision and acknowledgement are preserved throughout.
This module, selectable according to need, is part of Oronela in finalisation. Functions, responsibilities and interfaces form the fixed scope. Finalisation combines professional acceptance reviews with feedback from care institutions: real needs determine the final improvements.
Comparison with the module requirements, implementation plan and current Oronela system codebase: 1 October 2026. Product requirements M11-01–M11-05 · M11-A–D · Swiss billing 2027. The following areas are explained on this page:
