Claim Management
Manage your Claim frequency and manually generate Bulk Claim (BPR) Files
Last updated
Manage your Claim frequency and manually generate Bulk Claim (BPR) Files
Last updated
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.
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.
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.
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.
Invoice EntryThe 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:
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
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.
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.
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
Maica Claim Frequency = 1 hour via Maica Settings
Invoice and associated Invoice Line Item detail entered via Maica Invoice Entry with Claim 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:02AM
Claim 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 claiming
The Invoice Claiming process is described in more detail on the page below
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.
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:
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.
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.
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.
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.
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 the Status filter
Invoice Created Date is within the Start Date and End Date you specified in the filters (described above)
Or, for a more technical user:
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:
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 the Status has been updated to Resubmitted after the BPR Export
This represents the created Payment Request record to support the reclaim. The Status has been updated to Awaiting Approval
The Resubmitted Status value is only used when Claim Method = BPR File
Following the Bulk Payment Request (BPR) File export, the following fields are updated on the claimed Payment Request record:
Status
Awaiting Approval (detail below)
Claimed Amount
Invoice Line Item.Claim Balance
Claim Date
TODAY
NDIS Reference
Claim Reference Index (detail below)
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.
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
RegistrationNumber
The Provider's registration number as entered in Maica Settings
NDISNumber
Participant's NDIS Number on the Contact
SupportsDeliveredFrom
Service Date on the Invoice Line Item
SupportsDeliveredTo
Service Date on the Invoice Line Item
SupportNumber
Support Item Number of the Product provided on the Invoice Line Item
ClaimReference
Claim Reference on the Invoice Line Item
Quantity
Quantity on the Invoice Line Item
See note below for additional details.
Hours
Since Quantity is entered, this field is not required.
UnitPrice
Unit Price on the Invoice Line Item
GSTCode
GST Code on the Invoice Line Item
GST as applicable to the item or service.
P1 = Tax Claimable (10%)
P2 = GST Free
P5 = GST out of Scope
AuthorisedBy
Legacy field, can be left blank
ParticipantApproved
Legacy field, can be left blank
InKindFundingProgram
Not Applicable
ClaimType
Claim Type on the Invoice Line Item
Claim type of the service provided
- “(Blank)” – Direct Service. You must leave field blank.
- CANC: Cancellation
- REPW: NDIA Required Report
- TRAN: Provider Travel
- NF2F: Non-Face-to Face Services
CancellationReason
Cancellation Reason on the Invoice Line Item
Reason of the cancellation type
- NSDH: No show due to health reasons
- NSDF: No show due to family issues
- NSDT: No show due to unavailability of transport
- NSDO: Other
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 = 1
BPR UnitPrice = Claimed Amount
This is to ensure that the UnitPrice does not exceed the Price Book price, as this would be rejected by PRODA
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.
