For the complete documentation index, see llms.txt. This page is also available as Markdown.

Accommodation Balance Reporting

Providers must report each resident's refundable accommodation balance (RAD or RAC) to Services Australia every month, as required by the Aged Care Act 2024. The balance is reported as at the last day of the claim month, and reporting must be completed before the monthly claim can be finalised.

This article explains the accommodation balance record, the monthly submission workflow, and the gate that prevents a claim from being finalised while balances are outstanding. It is written for administrators and power users.

Why balances are reported

Accommodation balance reporting is a monthly reporting action, not a real-time or per-transaction one. The balance movements that occur during the month (a deposit, a top-up, a drawdown, a refund) are tracked internally by the billing engine as lump sum transactions. The accommodation balance submission is a separate, deliberate month-end step that communicates the closing balance position to Services Australia.

The lump sum account and its transactions are the provider's internal financial ledger. The accommodation balance submission is the external monthly report. To understand the ledger side, see The lump sum account model.

The accommodation balance record

Each monthly balance report is held as an Accommodation Balance record. One record is created per resident, per claim month, per submission. The record links to the resident's lump sum account and to the claim batch for the month, and it captures both what was reported and how the submission was received.

The fields below are the ones you will work with most often.

Field
API name
Description
Help text

Lump Sum Account

Lump_Sum_Account__c

The lump sum account this balance report relates to, which provides the balance amount and deposit type.

The resident's lump sum account (RAD or RAC) this balance report is for.

Claim Batch

Claim_Batch__c

The monthly claim batch that generated this submission, linking the balance to the claim cycle and the facility.

The monthly claim batch this balance was submitted as part of.

Balance Type

Accommodation_Balance_Type__c

The accommodation arrangement being reported for the resident, such as a refundable deposit, a contribution, or a supported resident with no lump sum.

The type of accommodation arrangement for this resident.

Balance Amount

Accommodation_Balance_Amount__c

The RAD or RAC balance as at the effective date, as submitted to Services Australia. Applies only to RAD and RAC balance types.

The accommodation balance amount submitted to Services Australia.

Balance Reason

Accommodation_Balance_Reason__c

The reason describing the main balance movement this month, such as a payment received, a refund, or no change.

The reason for the balance change this month (e.g. payment received, refund, no change).

Effective Date

Effective_Date__c

The date the balance is reported as at. This is the last day of the claim month, or the departure date for a resident who left during the month.

The date the reported balance applies to.

Submission Status

Submission_Status__c

The status of this balance report within Maica as it moves through submission, correction or deletion.

The current status of this balance submission in Maica.

SA Status

SA_Status__c

The status returned by Services Australia for the submission.

Whether Services Australia has accepted or deleted this balance submission.

Error Message

Error_Message__c

The error detail returned by Services Australia when a submission fails, so you can resolve it before resubmitting.

The error returned by Services Australia. Review and correct before resubmitting.

The submission lifecycle

The Submission Status field tracks where a balance report is in its lifecycle within Maica:

Status
Meaning

Pending

The record has been created but not yet submitted to Services Australia.

Submitted

Services Australia accepted the submission.

Failed

The submission was rejected or errored. The reason is in Error Message.

Corrected

A correction to a prior submission was accepted.

Deleted

The submission was deleted at Services Australia.

Services Australia itself recognises only two outcomes for a balance, reflected in SA Status: Accepted and Deleted. There is no held or superseded state for accommodation balances, unlike the event APIs. For the event status model, see Integration architecture and event lifecycle.

The monthly submission workflow

The submission is designed to run as a discrete step in the monthly claim cycle, after the billing engine has run and before the claim is finalised:

  1. The billing engine runs for the month, creating invoices and lump sum transactions.

  2. Maica polls Services Australia for the claim data.

  3. Accommodation balances are submitted for all eligible residents (the step described here).

  4. The unsubmitted balance gate check confirms no resident is missing a balance.

  5. The claim is finalised.

For each eligible resident, the submission derives the balance type, the balance amount as at month end, and the reason code from the month's lump sum transactions, then creates an Accommodation Balance record and submits it. A resident who already has a submission for the month is skipped, so the step is safe to re-run.

Corrections use the standard create, update and delete operations. A correction or deletion re-fetches the current Services Australia concurrency token first, so a change is never applied against a stale version of the balance.

The pre-claim gate

Before a claim is finalised, Maica asks Services Australia which residents it considers to be missing a balance submission for the month. This is the gate that enforces the legislative requirement to report balances before finalising.

  • If no residents are returned, finalisation proceeds.

  • If residents are returned, finalisation is blocked and the outstanding residents are listed so you can resolve them, either by re-running the submission or by submitting individual balance records.

Once the outstanding balances are resolved, you re-attempt finalisation and the gate check runs again.

For the claim finalisation step that this gate protects, see the Claims section of Inbound data APIs. For the resident-facing view of balances and refunds, see Refunding lump sum deposits in the User Guide.

Last updated

Was this helpful?