Systems Analyst 261112 or ICT Business Analyst 261111: How ACS Tells Them Apart
Why are these two codes easy to confuse?
Systems Analyst (261112) and ICT Business Analyst (261111) are two codes within the same ICT group, both assessed by ACS, and both involve analysing systems and requirements. Many people working in IT could genuinely fit either one — and the important question is not “which code am I more familiar with” but “which code more accurately describes the bulk of my work”.
Choosing the wrong code does not necessarily lead to an immediate refusal — but when ACS compares your file against the ANZSCO definition of the code you nominated, a file that does not match will be assessed negatively.
ANZSCO 261112 — Systems Analyst: what is the focus?
A Systems Analyst is someone who analyses and designs information systems to meet organisational requirements. The focus of 261112:
- Analysing existing systems: assessing IT systems already in operation — architecture, performance, limitations and scalability
- Designing technical solutions: producing the overall design for new systems or upgrades to existing ones — including data models, component design and integration design
- Technical specification: writing detailed technical documentation for developers to implement
- Feasibility study: assessing the technical feasibility of proposed solutions
- Working mainly with technical staff and developers to bring the design to life
Distinguishing keywords for 261112: system design, technical architecture, technical specification, feasibility at system level.
ANZSCO 261111 — ICT Business Analyst: what is the focus?
An ICT Business Analyst is the bridge between business requirements and IT solutions. The focus of 261111:
- Eliciting and analysing business requirements from stakeholders: business requirements, user needs
- Translating business requirements into actionable documentation: BRD (Business Requirements Document), user stories, use cases, process flows
- Analysing and optimising business processes tied to the IT system
- UAT and solution validation with end users
- Working mainly with business stakeholders and product owners, rather than primarily with technical staff
Distinguishing keywords for 261111: business requirements, stakeholder management, process analysis, user stories, UAT, bridge between business and IT.
Practical pairings: who is 261112 and who is 261111?
| Situation | Closer to which code |
|---|---|
| Designing the database schema and integration for a new system | 261112 |
| Writing user stories and acceptance criteria for a sprint backlog | 261111 |
| Assessing a system’s performance bottleneck and proposing a new architecture | 261112 |
| Interviewing end users to gather requirements | 261111 |
| Writing technical specifications for a developer team | 261112 |
| Writing a BRD and presenting it to leadership | 261111 |
| Designing API contracts and data flow between systems | 261112 |
| Running UAT and writing test cases from a business perspective | 261111 |
When you do both: how to decide?
Many people in a “Business Analyst” or “Systems Analyst” role actually do both kinds of work. In that case, you need to look at:
1. Your actual time split: If 60%+ of your time is technical analysis and system design — choose 261112. If 60%+ of your time is gathering requirements and working with the business — choose 261111.
2. Your main output:
- Technical specification / system design document → 261112
- BRD / user stories / process flows → 261111
3. Who you interact with more:
- Developers, DBAs, architects → 261112
- Product owners, end users, business stakeholders → 261111
You should not try to “optimise” by choosing the code with better visa conditions if it does not accurately describe your work — ACS assesses based on your actual evidence, and that evidence must be consistent with the code you nominate.
Common mistakes
Mistake 1: Choosing based on job title A “Systems Analyst” title on your contract does not automatically qualify you for 261112. ACS assesses the actual content of the work, not the job title.
Mistake 2: Inconsistency between the job description and the chosen code If your file describes BA work (stakeholder meetings, user stories) but nominates 261112, ACS will see the contradiction.
Mistake 3: A mixed description that does not make the focus clear If your file contains both system design and requirements gathering without making the primary role clear, ACS may find it hard to classify. Structure the description so the main focus stands out.
Mistake 4: Mistaking “Technical BA” for Systems Analyst Some people call themselves a “Technical BA” — this role usually still leans towards BA work (requirements, process), not system design. Look at the actual output, not the label.
How does the difference affect the visa?
Both 261111 and 261112 sit within the ICT Professionals group assessed by ACS. However, the specific visa conditions (subclasses 189, 190, 482, 186) can differ between the two codes at any given time — particularly in relation to the CSOL.
Check the current visa status of each code at immi.homeaffairs.gov.au before making a decision. The official website is the only reliable source for this.
See the visa pathway detail for each occupation in the related Systems Analyst (261112) and ICT Business Analyst (261111) articles.
How to present your ACS file
Once you have chosen a code, structure the experience description to focus on the characteristics of that code:
If nominating 261112:
- Clearly state the systems you have analysed and designed
- Describe your technical output: system design document, technical spec, architecture diagram
- Emphasise technical knowledge: data modelling, integration, performance
If nominating 261111:
- Clearly state the IT projects you took part in as a business-IT bridge
- Describe your BA output: BRD, user stories, process flows, UAT test plan
- Emphasise requirements elicitation skills and working with stakeholders
For more, see the related articles on a practical ACS file and on choosing the right ANZSCO code for IT occupations.