As an RTO, you're required under the conditions of your registration to report Total VET Activity to NCVER each year (comprising any students not already reported to a State Authority). This helps ASQA and others monitor training activity and needs nationwide, and provides students who have given you a USI with a central register of their training undertaken.

If you're a funded RTO, you have to make cleanliness and validity a focus each and every month - your business's very survival may rely on it; monthly lodgements force you to keep your data clean, up to date, and in good shape.

If you're predominantly fee for service, the annual scramble to report by 28 February can be worse than a chore - it can feel like a significant strain on your business at an already cash-strapped time coming out of the Christmas period.

Each year we help many RTOs, both Truss RTO clients and those using other systems, with their annual reporting obligations. Each year the challenges shift slightly, and many RTOs are caught on the back foot.


What's changed in 2017?

NCVER publish a list of validation rule updates regularly, the most recent being available here: https://www.ncver.edu.au/__data/assets/file/0009/10143/AVS_Validation_Update_Client_Information.pdf

There are a long list of validation rule adjustments that were rolled out over the course of 2016, most of which have little impact, but two rules in particular seem to have caused the most consternation this time around:


Problem 1: Duplicate Students (which the rules allow to occur in normal situations) are now a lodgement-blocking error:

We often deal with datasets, imported during data migration (or imported for the purposes of reporting) that have gaps. These gaps can occur for a number of reasons:

  • Insufficient validation rules in legacy systems (data entry is incorrect, but the system doesn't catch it)

  • Student refusal to fill out forms (particularly for short courses, especially when delivered for an employer, this is an ongoing challenge)

  • Poor data collection quality (primarily illegible handwriting on paper forms)

Importantly, this means that that there are data sets out there (which will validate for lodgement perfectly fine) where some students have no date of birth.

In this instance you may know from a recording perspective that "Jenny Smith, Client #12345, No Date of Birth" is a different person to "Jenny Smith, Client #34456, No Date of Birth", but you are required in your NAT80 file to report this student as a single line.

Beyond that, the rules are sufficiently fuzzy that they can catch complete and accurate information as invalid. We have one client, for example, who has three students with identical names & dates of birth, two of whom had training delivered in 2016, but they are different people. Because no USI was supplied, they show up as duplicates.


How do you solve this?

  • Deduplicate your student records

    This is extremely time consuming if your Student Management System doesn't already help you do this (ours automatically detects duplicates and helps you resolve them).

    Furthermore, if you have collisions that are genuine (same name, same date of birth, different people), there is literally nothing you can do without fudging your records - even if the students have different USIs they will be identified by NCVER as duplicates.

  • Record an exemption? Not yet

    You'll note in the rules above the rule does not apply if you're reporting one of the exemption codes now available for USI (e.g. "SHORT" in the USI field for a student who has attained units in a single day delivery).

    The problem? You can't lodge these codes for your 2016 data. They apply from 2017 onwards. So you're hamstrung by a new rule without being granted the tools to get around it. Frustrating!

  • Get Complete, Validated data for every single student? That's great - in theory

    We love to emphasise to our new & existing clients the advantages of electronic entry & validation of enrolment data by students - you can lock down eLearning content or certificate download behind supply of complete and valid AVETMISS data, and leave it up to the student to correct information rather than paper collection which can be riddled with errrors.

    That's all well and good, but in real life there are always exceptions - students who don't have a smartphone, job network providers whose students have poor technical literacy and no access to a computer, or myriad other things that could go wrong. You also have the occasional recalcitrant student who just flatly refuses to supply a USI (or even AVETMISS data).

    Which again, leaves you stuck with the first option - deduplicating after the fact, and in some cases forced to "merge" students who should not be merged.



Problem 2: Duplicate Unit Outcomes are a lodgement-blocking error, and can occur in normal use:

This change was actually introduced for the 2015 reporting year, but still stumps many RTOs:



Your NAT120 file must have no duplicate entries for Location, Client Identifier, Subject, Program, and Start Date. We will detect and highlight duplicates, but sometimes that comes too late, especially if we've imported the data. 

We find it's common that RTOs accidentally enrol students multiple times, both in legacy systems and in our own. In cases of this data quality issue, this validation error is helpful, as it will prompt the RTO to purge unnecessary duplicates.

By contrast, big problems can arise here when you deliver overlapping content in short courses, where ostensibly correct information again results in a validation error.

Here's a real world example of overlapping content:

  • UETTDRRF06B Perform Rescue from a Live LV Panel
    This includes HLTAID001 Perform Cardiopulmonary Resuscitation as part of its content; as such you should report it as both UETTDRRF06B and HLTAID001.

  • HLTAID003 Provide First Aid
    This also includes the content of HLTAID001 and HLTAID002, and should report as all three units.


So let's say you have an Electrical Subcontractor client who asks you to deliver both LV Rescue and Provide First Aid to their staff.

As the content stretches over more than one day, you sensibly decide to schedule two days to deliver the content as a custom program.

So over the two days, you start and finish the following units on the same dates:

  • UETTDRF06B
    • incorporating HLTAID001
  • HLTAID003
    • incorporating HLTAID001
    • incorporating HLTAID002

This then leaves you with a duplication error for all the students on HLTAID001. Most Student Management Systems out there will allow this; some may prompt you to resolve it.

Especially for clients we assist with lodgement of data imported from their external systems, there are sometimes north of a thousand instances of this in a calendar year - that's real, "correct" information - not actual duplicate enrolments.

How do you solve this?

  • Cancel/remove one of the units.

    Fundamentally, for reporting purposes, it doesn't actually matter for fee for service which row you eliminate, as they report the same thing, and it doesn't make sense to have delivered the same unit twice to the same student on the same day.

    Some student management systems make it harder than others, but in ours, we allow for an easy flagging of duplicate units to exclude from reporting. This means the student will still see completions for the full overlapping programs in their student portal (and on transcripts), but your data will validate and lodge cleanly.


How we help

When our clients are preparing their NCVER lodgement, Truss RTO presents a list (or table if there are many) of anticipated validation errors before generation of a NAT file batch:



Clicking through then gives you a simple hitlist of items to resolve:


Then clicking "Resolve" opens the problematic record, with problematic fields highlighted for resolution.

Resolving the issue then flushes it out of your list.

Chipping away at these issues until you reach an endpoint and are ready to lodge is several orders of magnitude quicker than going through AVS validation reports!


Don't panic - ask for help

If you're stuck with these or other NCVER lodgement troubles, we can help - give us a call on 1300 221 475.

You don't have to sign up for our product, we're happy to assist with AVETMISS Rescue services with no ongoing obligation.

We've helped RTOs correct batches ranging from 100 students to 100,000 on a turnaround of a few days. Send us your invalid NAT files, we'll help you clean them up, then deliver lodgeable NAT files and an audit report of what needs to be changed in your current systems.

comments powered by Disqus