"AVETMISS compliant" appears on roughly every Australian RTO software vendor's homepage. The phrase has lost meaning. Some platforms genuinely produce valid AVETMISS submissions; others can technically generate a NAT file but produce one full of validation errors that AVS rejects on first submission.
If you are searching for AVETMISS compliant software, the right test is not the marketing claim. It is whether the platform produces NAT files that AVS accepts on first submission, every quarter, without your admin team manually fixing rows.
One thing up front: the RTO is responsible for AVETMISS submissions, not the software. Your team submits to NCVER and is accountable for what goes through. The platform's job is to make that submission accurate; it does not take over the obligation.
Here is what genuine AVETMISS compliance in software actually requires.
NCVER code list currency
NCVER code lists are not static. They update on a defined cycle — Indigenous Status, Country of Birth (SACC 2016), Language Spoken at Home (ASCL 2016), Funding Source — National, Outcome Identifier, and others. A platform that hard-coded a 2018 Funding Source list and has not updated it will produce rows AVS rejects.
Genuinely AVETMISS compliant software:
- Tracks NCVER code list versions explicitly
- Updates when NCVER publishes a new release
- Validates new submissions against the current list
- Surfaces changes to RTO users so historical data can be reviewed if needed
If the vendor cannot tell you which NCVER release the platform is currently aligned to, that answers the compliance question.
Validation at capture, not at submission
A generic SMS lets you save a Client record with an invalid State Identifier, an out-of-range Indigenous Status code, or a future-dated Activity Start Date. The errors only surface three months later when AVS rejects the submission and someone has to track down the bad rows.
Compliant software validates at the point of data entry. The form rejects the invalid State Identifier when the user clicks save, not when AVS rejects the file. This is the single biggest difference between "produces a NAT file" and "produces a NAT file that submits cleanly."
The full NAT file set
AVETMISS is not one file. It is a set of NAT files that have to be consistent with each other — Training Organisation, Delivery Location, Program (qualification/course), Subject (unit of competency), Client, Client Postal Details, Prior Educational Achievement, Disability, Enrolment / Activity (NAT00120), Program Completed.
Compliant software produces all of them with referential integrity — a NAT00120 row's Client Identifier matches an actual NAT00080 Client, every Subject Identifier matches a real Subject, every Program code matches a registered qualification on your scope. A platform that exports "the AVETMISS file" and means just NAT00120 is not actually producing a complete submission.
USI verification
USI verification has to happen before the unit attempt is reported. Compliant software:
- Verifies the USI against the registry at enrolment time
- Stores the verification result and date
- Blocks reporting of unit attempts for unverified USIs
- Surfaces students whose USI verification has failed for follow-up
If your software lets unit attempts be reported for students with unverified USIs, you have a compliance gap that will surface at audit, not just at submission.
The VDS Program transition
AVETMISS as currently submitted is being replaced by the VET Information Standard (VIS), submitted via the STARS API under the VDS Program. Mandatory by 31 December 2028. Stage 1 went live for fee-for-service RTOs in July 2025.
Genuinely compliant software is mapping its data model to the VIS schema now, not after the deadline panic. Ask the vendor directly: "Are you in the VDS Developer Portal? Have you tested STARS submissions?" The answer separates platforms that will be ready from platforms that will scramble.
Records retention and post-submission amendments
AVETMISS submissions do not end when AVS accepts the file. Errors surface later. Outcomes change. RPL grants are decided after submission. Compliant software supports post-submission amendments cleanly, with the amendment history visible per record, and the USI transcript re-sync triggered when an outcome changes.
A platform that treats submission as a one-way export is going to leave you reconciling AVS records and live records over and over.
What to ask any vendor
- Which NCVER code list release are you currently aligned to, and how do you handle updates?
- Is validation enforced at capture, or only at NAT file generation?
- Do you produce the complete set of NAT files with referential integrity, not just NAT00120?
- Is USI verification enforced before unit reporting, or just recorded?
- Are you VDS Developer Portal-registered, with STARS submission testing in progress?
- How are post-submission amendments handled — is there a clean amendment trail and USI re-sync?
Where RTO Grow fits
RTO Grow is built around the AVETMISS data model, with current NCVER code lists, capture-time validation, full NAT file generation with referential integrity, and a VIS-mapped schema for the VDS STARS API transition. Post-submission amendments are first-class workflows, not edge cases.
We do not certify your compliance — your team does. What we do is make sure that when the AVS submission window opens, your data is already in the shape that submits cleanly.
See our AVETMISS reporting page or book a demo for the difference between "produces a NAT file" and "produces a NAT file AVS accepts."