"AVETMISS compliant" is the most over-used phrase in Australian LMS marketing. Almost every vendor claims it. Very few mean it the way NCVER does. If you are searching for an AVETMISS compliant LMS, the question is not whether the platform claims compliance — it is whether the data it captures actually populates a NAT file row without admin intervention.
One thing up front: the RTO is responsible for AVETMISS compliance, not the LMS. Your compliance team is accountable for what gets submitted to NCVER and AVS. The LMS's job is to give them clean, validated, code-correct data. The submission stays with humans.
Here is where most "AVETMISS compliant" LMS platforms quietly fall short.
Outcome Identifier — National
Every unit attempt has to be reported with an NCVER Outcome Identifier — National. Common values include:
- 20 Competency Achieved / Pass
- 30 Competency Not Achieved / Fail
- 40 Withdrawn
- 51 Recognition of Prior Learning Granted
- 60 Credit Transfer
- 70 Continuing Enrolment
Plus state-specific outcomes in the Outcome Identifier — State Training Authority field for funded RTOs.
A genuinely AVETMISS compliant LMS captures the outcome at the assessment layer, with the correct NCVER code, against the right unit version, on the right date. A generic LMS marked "AVETMISS compliant" captures "Pass" or "Fail" as a label, and someone in admin translates later.
That translation is where errors hide.
Hours Attended
NAT00120 requires Hours Attended for each enrolled unit — actual hours, not scheduled. A generic LMS records SCORM session time and considers it done. That is not Hours Attended; it is content engagement time.
An AVETMISS compliant LMS has to:
- Capture attendance at face-to-face and virtual sessions
- Aggregate hours against the specific unit being delivered, not the whole course
- Distinguish supervised online learning from unsupervised
- Allow correction of errors with an audit trail
If your "compliance" report has zero hours for half your students because the LMS only knows SCORM time, you are not actually AVETMISS compliant.
Predominant Delivery Mode
This trips up most platforms. Predominant Delivery Mode is reported per enrolled unit, with NCVER-coded values covering internal (face-to-face), external (online distance), workplace (supervised on-the-job), internet-based asynchronous learning, and not-applicable (RPL, Credit Transfer).
A generic LMS records "online" or "in-class" as a free-text field at the course level. AVETMISS needs the code at the unit-attempt level, because the same student in the same course can have different modes for different units.
An AVETMISS compliant LMS captures this at the right granularity, with the right code list, at the right point in the workflow.
Activity Start Date, Activity End Date, Outcome Date
Three different dates, all required, all distinct:
- Activity Start Date — when the student first engaged with the unit
- Activity End Date — when activity stopped (whether competent, withdrawn or expired)
- Outcome Date — when the assessor's decision was recorded
A generic LMS often conflates these or only captures one. NAT00120 needs all three, and if Outcome Date precedes Activity Start Date your AVS submission will fail validation.
Funding Source — National and State
For funded RTOs, every enrolment row needs Funding Source — National (federal program code) and Funding Source — State Training Authority (state contract code). These come from the enrolment, but they have to flow through to the LMS so they are attached to the unit attempt at outcome time.
If your LMS does not know whether a student is fee-for-service, VET Student Loan, or funded under a specific state contract, the outcome it records will not make it to the right NAT00120 row without manual reconciliation.
What "AVETMISS compliant" actually requires of an LMS
To honestly call itself AVETMISS compliant, an LMS has to:
- Capture Outcome Identifier — National at the unit-attempt level, using current NCVER codes
- Track Hours Attended at the unit level, separate from content engagement time
- Record Predominant Delivery Mode per unit attempt with NCVER codes
- Distinguish Activity Start, Activity End and Outcome Dates as separate fields
- Carry funding source data from enrolment through to outcome
- Validate against NCVER code lists at the point of capture, not at submission
- Generate NAT00120 rows that pass AVS validation without admin re-keying
Anything less is engagement-tracking software with a marketing claim attached.
What to ask any vendor
- Does the LMS produce a complete NAT00120 row per unit attempt without admin translation?
- Are NCVER outcome codes captured at the assessment layer, not as free text?
- Is Hours Attended captured at the unit level, separate from SCORM session time?
- Does Predominant Delivery Mode use NCVER codes per unit, not free-text per course?
- Are validation errors caught at the point of capture, not at AVS submission time?
Where RTO Grow fits
RTO Grow treats AVETMISS as the native data structure of the LMS, not a reporting export. Outcome codes, hours, delivery mode, activity dates and funding source all live at the right granularity from the moment the unit is enrolled. NAT00120 rows are not generated; they are queried.
We do not certify your compliance — your team does. What we do is make sure the data your team submits is structured correctly the first time, every time.
See our AVETMISS reporting page or book a demo to see a live NAT00120 row generated from a real student's unit attempt.