Two project reports decide most ACS RPL outcomes, and the gap between a pass and a resubmission usually sits inside one section of them. The ACS RPL project report requirements are short to list but strict to meet: two original reports, each tied to skills under your nominated ANZSCO code, each showing the technical decisions you made rather than the tasks you were handed. This guide walks every requirement section by section, then sets a passing paragraph beside a failing one so you can benchmark your own draft before an assessor ever reads it.
What an ACS RPL project report is, and when you need one
The Recognition of Prior Learning pathway exists for ICT professionals whose skills come from work rather than a closely matched Australian qualification. Your two project reports are where you prove those skills in your own words, in first person.
How the reports differ from a CDR or a skills summary
A quick terminology check saves grief later. The ACS RPL report is not a CDR, and it does not contain career episodes. Those are Engineers Australia terms for a different assessing body, and importing that structure is a common early mistake. An ACS project report is also not a duties summary or an expanded résumé. It is a first-person account of a real project that demonstrates specific ICT knowledge areas mapped to your occupation.
Where the two reports sit in your submission
Alongside the reports, your application carries identity documents, employment references, professional currency evidence, and payment records. The project reports are the narrative core; everything else is corroboration. If you are still weighing your route, our ACS skills assessment pathways explainer sets RPL against the qualification-based pathways.
If your role was never project-based
Not every ICT career is built on discrete projects. ACS names this case directly: applicants in non-project roles supply details of their work experience and the challenges faced during their tenure instead of two project narratives. If your work is continuous operations, support, or administration, structure each report around a significant problem you personally owned and resolved, rather than forcing an artificial project wrapper around routine duties.
Before you write: three things to confirm first
Your ANZSCO code and the skills it tests
Everything in your reports is judged against one occupation. Confirm your nominated ANZSCO code first, then read the skill areas it maps to, because a report full of impressive work in the wrong domain earns nothing. A 261313 Software Engineer report built around network administration demonstrates skills the assessor is not there to measure.
Which projects count as ICT work
Choose projects where you personally applied ICT knowledge and made technical calls. Work you merely coordinated, or where your contribution was purely managerial, is hard to evidence and easy for an assessor to discount.
Documents to have ready for each report
Each project needs backing: a reference confirming your role and dates, and evidence of the work itself where you have it. Freelance and contract projects are fully acceptable, provided a signed client reference or statement of service supports them. Gather these before drafting, because a strong narrative with nothing to corroborate it is still a weak claim.
ACS RPL project report requirements: structure and length
Here is where the ACS RPL project report requirements get concrete.
How many reports, and choosing your two projects
ACS requires exactly two project reports, and their timing matters. Per the ACS InfoHub, one project must fall within the last two years and the other within the last four years. Many competitor guides still circulate a "three years and five years" rule that the ACS source does not support. Use the two-and-four-year window, and pick two distinct projects that together cover the breadth of your claimed occupation.
The four sections every report must cover
The ACS RPL Form organises each report around four elements: a project summary, the business problem or opportunity, your solution, and the results. In plain terms, the assessor reads for what the project was and your role in it, the technical knowledge you applied, the tools and methods you used, and the outcome you personally delivered. Of these, the solution section, where your technical knowledge and decisions live, carries the most weight and fails most often.
How long each report should run
ACS does not publish a rigid word cap in its guidance, so treat length as a function of evidence rather than a number to hit. A working range of roughly 1,000 words per report, about 2,000 words across both, gives enough room to show real decisions without padding. Always write to the current ACS Recognition of Prior Learning Form (2024 v2), which is the authority on format.
How to write each section of a project report
Project background and your role
Open each report by placing the reader: the organisation, the project's purpose, its scale, and precisely where you sat in the team. State your responsibilities in the first person. Because assessors have to separate your contribution from the team's, "the team delivered" is far weaker than "I designed and owned."
Technical knowledge and the decisions you made
This section passes or sinks a report, and it is the one applicants most often get wrong. Do not narrate tasks. Show judgment: the options you weighed, the constraint that eliminated one, the trade-off you accepted, and the reasoning behind the call. For each significant decision, an assessor wants to see that you understood the problem, knew the alternatives, and could defend your choice on technical grounds. One well-explained decision demonstrates more skill than a page of activities. Map each decision, even loosely, to a knowledge area under your ANZSCO code so the assessor can connect what you did to what they are measuring.
Tools, technologies, and methodologies
Name specifics. "A relational database" tells an assessor nothing; "PostgreSQL 14 with a normalised schema, provisioned through Terraform" shows applied knowledge. State the methodology you worked under, whether Scrum, Kanban, or a staged waterfall, and describe how you actually used it rather than dropping the label.
Outcome and what you personally delivered
Close on results tied back to your work. Quantify where you honestly can, whether throughput, uptime, cost, or defect rate, and attribute the part you owned. A vague ending like "the project was a success" wastes the most persuasive position in the whole report.
ACS RPL project report sample: annotated walkthrough
Rules stay abstract until you see them applied. Below is the same migration work written twice: first as the task list that gets flagged, then as the decision evidence ACS wants.
The rejected task-list paragraph
> I was responsible for migrating the company's on-premises servers to the cloud. I installed and configured the virtual machines, set up the networking, created the user accounts, and tested the applications. I documented the process and trained the support team afterwards.
Everything here is true, and nothing is assessable. It reads like a job description rather than a demonstration of skill, lists activities almost any team member could claim, names no technology, and reveals no judgment. An assessor cannot map a single ICT skill to a decision you made, because there is no decision on the page.
The same work, rewritten as decision evidence
> Migrating 40 on-premises servers to AWS, I chose a phased lift-and-shift for the legacy billing application because its licensing was bound to fixed MAC addresses, which ruled out re-architecting it into containers inside the project timeline. Instead of matching the old hardware specs, I sized the EC2 instances from three months of CPU and memory profiling, which lowered the projected compute cost. To protect the nightly billing run during cutover, I designed a parallel-run window and reconciled output from both environments before decommissioning the source hosts.
Same project, same word budget, completely different signal. The rewrite names the technology, exposes the real constraint, defends a specific choice, and ties the outcome to a call only the author could have made. That is the benchmark for every paragraph in your solution section.
Supporting documents ACS requires by project type
Your evidence depends on how you were engaged. ACS assesses reference and payment evidence against the nature of your work, so match your documents to your project type. The table below maps the common cases to what ACS's evidence categories expect.
Project type | Supporting documents to provide |
|---|---|
Salaried employment | Employment reference letter on company letterhead stating role and dates, plus payslips or tax records as payment evidence |
Contract through an agency or client | Signed client reference or statement of service confirming your role and dates, plus your contract or invoices |
Freelance | Statement of service or a signed client reference, plus invoices or payment records |
Open-source contribution | Verifiable commit history or a maintainer's reference confirming your specific contributions |
Whatever the type, the reference has to confirm what you claim in the report. A report describing architecture decisions backed only by a payslip leaves the role itself unproven.
Mistakes that get a project report rejected
Copying or paraphrasing online samples
ACS reserves the right to check project reports against published material for similarities, and if undeclared non-original content is detected, you may be asked to resubmit. Paraphrasing a downloadable sample is nearly as risky as copying it, because the underlying structure and phrasing still echo indexed sources. Write from your own projects. Our guide to avoiding ACS RPL plagiarism flags covers what triggers detection.
Describing work outside your ANZSCO occupation
A well-written report about skills your occupation does not test earns no credit. Every major section should trace back to a skill area under your claimed code.
Two reports covering the same project
Your two reports exist to show breadth. Two accounts of the same project, or the same role viewed from different angles, hands the assessor one data point where they expect two. Choose genuinely distinct projects.
FAQs
How many project reports does ACS require for an RPL application?
Exactly two. Each must cover a distinct ICT project, with one project completed within the last two years and the other within the last four years, per the ACS InfoHub.
What is the required word count for each ACS RPL project report?
ACS does not publish a fixed word limit. A practical target is around 1,000 words per report, roughly 2,000 words in total, which is usually enough to evidence your decisions without padding. Write to the current ACS RPL Form for the authoritative format.
Can I use a freelance or contract project in my ACS RPL report?
Yes. Freelance and contract work is accepted when a signed client reference or statement of service confirms your role, responsibilities, and dates. The document has to corroborate the contribution you describe in the report.
Can one project serve both report and currency evidence?
A single project may appear in both your project report and your professional currency evidence, so some overlap is possible, but do not let one stand in for the other. Your project reports evidence applied skills; professional currency evidence shows recent, ongoing engagement with the field.
What makes ACS reject a project report during assessment?
The leading causes are vague task lists with no decision evidence, work that does not map to the claimed ANZSCO occupation, content flagged for similarity with published material, and two reports covering the same project.
Once your project reports are drafted, check them against the most common ACS RPL rejection reasons before you submit. Our rejection self-audit guide lists exactly what assessors flag, so you can fix problems while they are still cheap to fix.