Claim Management
Manage your Claim frequency and manually generate Bulk Claim (BPR) Files
As Plan Managers and Delivery Providers, claiming payment for your services is about as important as it gets. Maica provides the flexibility to ensure you have the time needed to validate Payment Requests before they are submitted to PRODA and also provides the ability to continue claiming even in the event of technical issues with the Agency's API via the Bulk Payment Request (BPR) File.
Claim Management Settings vs Invoice Entry Claim Behaviour
Before detailing how your overall Claim settings can be configured within Maica, we thought it would be a good idea to give you a quick overview of how the settings are applied as this can change based on where you are in Maica.
Claim Management - Maica Settings
The Claim Management
settings within the Maica Settings tab are used to define your overall or organisation-wide default Claim Settings. Essentially, these Claim settings are the ones that will be applied if your users make no change at the point of Invoice Entry (defined below). You can learn more about the Claim management settings in this article.
Claim Behaviour - Invoice Entry Component
The Claim Behaviour
drop-down on the Invoice Entry component allows your users to define how a specific Invoice
should be claimed. These settings apply on an individual basis, meaning that they are only applied to the Invoice
being entered. Once the Invoice
is submitted, the Claim Behaviour selection is cleared and ready for the next Invoice.
You can learn more about the Invoice Entry component via the link below.
pageInvoice EntryClaim Method
The first setting you will see is called Claim Method. This is used to tell Maica how you would like to claim Payment Requests (entered in the form of Invoice and Invoice Line Item records) from PRODA.
The Claim Method drop-down contains the following two values:
API
Setting Claim Method to API
is the most automated option and the one that leverages the integration strength of Maica and PRODA.
API means Payment Request
records will be automatically created and submitted to the NDIS for processing based on the Claim Frequency
settings (defined below) and on the Invoice Entry component.
Once a Payment Request has been submitted to PRODA, it will also be automatically updated with the Result, i.e. Success/Fail and the Remittance information, i.e. Amount Paid when this is made available by PRODA.
The Result update is real-time and provided once the Payment Request has been submitted to PRODA. The Remittance update is made when this notification (webhook) is triggered by PRODA. Maica does not control when this is received from PRODA.
If your Claim Method
is set to API
, only the following values are available in the Invoice Entry component:
Use Claim Settings
Claim Immediately
Under Review
Do Not Claim
BPR File
Setting Claim Method to BPR File
uses the more traditional file-based claiming solution.
BPR File means Payment Request
records will be automatically created but not submitted to the NDIS for processing. In order to submit the Payment Request
, you need to generate the Bulk Payment Request (BPR) File via the Generate Bulk Payment Request section described below. You can then upload this file via the myplace provider portal.
These Payment Request
records will be created with Status
= BLANK
If your Claim Method
is set to BPR File
, only the following Claim Behaviour
values are available in the Invoice Entry component:
Claim via BPR File
(default)Under Review
Do Not Claim
It is important that you do not toggle from BPR File
to API
with an open, or unfinished, claiming cycle. If you have generated Payment Request
records with the Claim Method
= BPR
, these cannot be claimed via the API.
Claim Frequency
Use the Claim Frequency setting to provide your team with the ability to review and validate Invoice
and associated Invoice Line Item
records before Payment Requests are generated and automatically sent to the NDIS Portal for Claiming.
Essentially, you can use the wait setting to specify the duration (hours) to pause before creating Payment Request
records in Salesforce that are submitted for claiming in the NDIS Portal.
Let's see it in action:
Once a Claim Frequency
value is saved via Maica Settings, any Invoice
created via the Maica Invoice Entry app can leverage this setting. In order to do this, select the Use Claim Settings
value in the Claim Behaviour
pick list (see below).
Once the Invoice
is entered, the following fields are populated on the Invoice record:
Claim Behaviour
=Use Claim Settings
Claim Scheduled At
=CreatedDateTime
+Claim Settings Wait Period
Claim Frequency - Invoice Entry Flow
Maica
Claim Frequency
= 1 hour via Maica SettingsInvoice
and associatedInvoice Line Item
detail entered via Maica Invoice Entry withClaim Behaviour
=Use Claim Settings
The
Invoice
(and any associated Invoice Lines) are created in Salesforce with the following properties:Created Date
= 16/6/2022, 7:02AMClaim Behaviour
=Use Claim Settings
Claim Scheduled At
= 16/6/2022, 8:02AM
Once Claim Scheduled = the current date and time, the
Payment Request
records will be automatically generated by Maica for each Invoice Line Item and submitted to the NDIS Portal for claimingThe Invoice Claiming process is described in more detail on the page below
Bulk Payment Request (BPR) File Generation
Maica has you covered in the event of technical issues with the Agency's API, you can generate a Bulk Payment Request (BPR) File and upload it to the myplace provider portal, hassle free! The BPR file enables you to submit multiple requests for payment in a single file uploaded via the Provider Portal, rather than submitting individual requests for each Service Booking for each participant.
Once the Bulk Payment Request File is generated, you can go straight to the myplace Provider Portal and upload it directly to Bulk Payment Request Upload as the file that Maica generated for you is compliant and according to the template provided by the NDIS.
BPR File Process Overview
Before we show you how to use the Bulk Payment Request (BPR) File, we should probably give you a quick overview of the BPR process and the different steps in the process. This part is important as in order to successfully use the BPR files, there is a 3 step process that must be completed sequentially or in the order outlined below:
Step 1: Bulk Payment Request (BPR) File
The Request file refers to the initial file that is downloaded from Salesforce containing the details of the Payment Request
data you wish to submit to PRODA to claim.
Step 2: Bulk Payment Request Results (BPR) File
The Results file refers to the file downloaded from PRODA containing the import results (Success/Fail) for each Payment Request
included in your BPR Upload completed in Step 1.
Please note: whilst the BPR Results file contains payment information within the file, Maica does not use this to update the Payment Request
payment information as the Remittance file is used for that purpose.
Step 3: Bulk Payment Request Remittance (BPR) File
The Remittance file refers to the file downloaded from PRODA containing the actual payment results for each Payment Request
included in your BPR Upload completed in Step 1.
Now, continue with the section below to learn how to complete the first step in the process, or generate the Bulk Payment Request (BPR) File from Maica and Salesforce.
BPR File in Action
Once you're in the Claim Management section of Maica Settings, completing the Bulk Payment Request File is a few clicks away.
Before you click Generate CSV, there is a one-time setup to enter your Registration Number
. This is the registration number shown in your Provider Portal Profile as Organisation ID
.
Next, apply the necessary Date Range and any specific Payment Request Status
values you will like to filter on. For reference, the Date Range filters uses the Invoice
Created Date
, meaning any Invoice
records added to Salesforce within the Start Date and End Date will be searched.
For the Status
filter, only the following Payment Request
Status
values are available for filtering:
Blank
Failed
Incomplete
Cancelled
Rejected
In regards to the Payment Request Status
Filter, we recommend always including the Blank
value as this will include all records within the Date Range that have not previously been included in a BPR file.
The other values (Failed
, Incomplete
, Cancelled
, Rejected
) allow you to retry or reclaim a previously failed Payment Request
The exclude option allows you to indicate whether there are particular Providers or Invoices you wish to exclude from the BPR File. Anything specified in this section will not be included in the CSV file generated
When that is done, Maica will display a count of all Payment Request
records found that match your criteria. If you are comfortable with the number displayed, click Generate CSV and Maica will work the necessary magic to generate the BPR file for you! As part of the file generation and download, Maica performs a number of very important updates. These are defined in the Post BPR File Generation section below.
The myplace Provider Portal only supports up to 5000 rows in an uploaded BPR File, meaning if your filter criteria returns a result set containing more than 5000 rows, Maica will present the error below and not allow you to complete the process.
The following error will be displayed:
The results of the date range and status criteria selected exceeds 5000 records. Please adjust your criteria to refine the results.
BPR File Query Summary
How does Maica determine what Payment Request
records to include in the BPR file? Great question! The BPR file will be populated based on the following criteria:
Payment Request
Status
= the value(s) selected in theStatus
filterInvoice
Created Date
is within theStart Date
andEnd Date
you specified in the filters (described above)
Or, for a more technical user:
Post BPR File Generation
Once the Bulk Payment Request (BPR) File has been generated, a few specific actions are completed by Maica to complete this first step in the BPR Claiming process. These actions are defined below:
New Payment Request Created (Reclaimed Payment Requests)
When generating the BPR File, if your Status
filter contained a value other than Blank
, this means that it has already had a previous claim attempted, either via the BPR File or API, and a new Payment Request
record is required to facilitate the new claim.
The reason being that PRODA requires the Payment Request
, specifically the Claim Reference
used, to be unique. So essentially, a Payment Request
is only ever good for single use.
In this scenario, we need to attempt to claim the funds again, i.e. reclaim, therefore a new Payment Request
record is required for this.
To handle this as part of the BPR File scenario, when you generate the BPR File, the previously attempted Payment Request
record will be cloned and a new Payment Request
record will be created with the Status
= Awaiting Approval
(regardless of the status of the previous Payment Request
record).
Additionally, the Status
of the source, or cloned, Payment Request
will be updated to Resubmitted
to reflect the fact it has been reclaimed with PRODA. You can see this in the screenshot below, where:
This represents the original, cloned
Payment Request
record where theStatus
has been updated toResubmitted
after the BPR ExportThis represents the created
Payment Request
record to support the reclaim. TheStatus
has been updated toAwaiting Approval
The Resubmitted Status
value is only used when Claim Method = BPR File
Payment Request Update - Field Updates
Following the Bulk Payment Request (BPR) File export, the following fields are updated on the claimed Payment Request
record:
Payment Request Field | Value |
---|---|
|
|
|
|
|
|
|
|
Payment Request Update - Status
It is important for the Payment Request
record to reflect that it has now been included in a BPR File for claiming via PRODA.
In order to do this, Maica updates the Status
of the Payment Request
record(s) included in the BPR file to Awaiting Approval
.
The next Payment Request
Status
update will be handled by the BPR Results file
The image below provides a view of a Payment Request
record that has been included in the BPR File.
Payment Request Update Claim Reference Index
To keep the values consistent within the Payment Request
record, the BPR File export also sets the Payment Request
NDIS Reference
field = Claim Reference Index
field.
Essentially this is to ensure that the NDIS Reference
field is populated whether you are claiming via the API or the BPR File.
When claiming via the API, the Claim Reference
is not used as the NDIS do not request this value. Rather, the API Reference is returned from PRODA which is populated in the NDIS Reference
field by Maica
BPR File Template Definition
Template Field Name | Information |
---|---|
| The Provider's registration number as entered in Maica Settings |
| Participant's |
|
|
|
|
|
|
|
|
|
|
| Since |
|
|
|
|
| Legacy field, can be left blank |
| Legacy field, can be left blank |
| Not Applicable |
|
|
|
|
Quantity Logic
In the reclaim scenario, i.e. an additional claiming attempt, the Quantity
value populated in the BPR File may be different to the initial claiming attempt. This logic is summarised below:
When Payment Request
.Claimed Amount
> Invoice Line Item
.Unit Price
set:
BPR
Quantity
=Claimed Amount
/Unit Price
BPR
UnitPrice
=Unit Price
Otherwise set:
BPR
Quantity
= 1BPR
UnitPrice
=Claimed Amount
This is to ensure that the UnitPrice does not exceed the Price Book price, as this would be rejected by PRODA
Sample BPR file generated
For further assistance once you have the BPR File, with processing bulk requests in myplace provider portal, see this page or watch this video tutorial.
Last updated