An ImmiAccount application for a partner visa runs to hundreds of fields across two applicants and a sponsor: ten years of addresses, every trip outside Australia, employment history, family composition, the long character and personal-particulars question sets. Almost all of it is already sitting in your case management system, typed once by the client in a questionnaire and checked by you. Typing it a second time into the Department's form is the single largest block of unbilled, error-prone hours in a lodgment.
Auto-fill tools exist to remove that second typing. This guide explains what ImmiAccount auto-fill is, how a browser-based tool actually works, where the hours go, what such a tool must never do, and the review discipline the Code of Conduct expects when a machine has put the words on the page.
What ImmiAccount auto-fill is
ImmiAccount auto-fill is a browser extension that, while you are logged into ImmiAccount yourself and have an application form open, reads the client's verified data from your case management system and populates the fields on the page in front of you. You pick the client, you choose to fill the page, you check what it entered, and you move to the next page. The extension does not log in for you, does not decide what to apply for, does not make the declarations and does not submit. It is a typing assistant with the file open beside it.
That definition matters because the phrase is used loosely. Copy-and-paste macros, spreadsheet-to-form scripts and "lodgment bots" that promise to lodge while you sleep all get called auto-fill. Only the first kind, prefill under the agent's eye, fits inside a compliant practice.
How a prefill extension works
There are three parts, and a vendor should be able to describe each of them to you.
A structured source. The data has to exist as fields, not prose: a date of birth as a date, a passport number as a passport number, an address history as a list of addresses with from-and-to dates. That is what a subclass-specific questionnaire produces and a generic intake form does not. The quality of the fill is the quality of the questionnaire.
A mapping. Each ImmiAccount form asks its questions in its own order and wording, and repeating sections (addresses, travel, employment, family members) are sub-forms that have to be added one record at a time. The extension carries a map from your data model to each form's fields, including those repeating sub-forms, and the map has to be maintained as the Department changes its forms. This is the hard part of the product and the reason coverage differs between forms.
A narrow runtime. The extension should run only on the lodgment sites, send data only between your browser and your own case management account, and do nothing in the background. In the LodgeHQ eLodge extension, published on the Chrome Web Store, the fill is triggered from the extension icon on the page you are viewing: pick the client, click Fill current page, and the fields LodgeHQ holds questionnaire data for populate, including repeating records for addresses, travel, employment and family, the sponsor sections on an employer-sponsored application, and the genuine-student and character question sets. Coverage varies by form and by how complete the questionnaire is, and the tool never claims completeness: a field it cannot answer with certainty is left for you rather than guessed.
Where the hours actually go
Not all fields are equal. The time saved is concentrated in a handful of sections that are long, repetitive and identical across the family unit:
- Address history. Ten years, every move, for every applicant, with dates that must not leave gaps.
- Travel history. Every departure and return, with countries and dates, often for several applicants with overlapping trips.
- Employment and education history. Employer names, addresses, dates, positions and duties.
- Family composition. Parents, siblings, children and partners of every applicant, each with their own names, dates of birth and locations.
- Character and personal-particulars questions. The long question sets that repeat across applicants and across applications for the same client.
- Sponsor and nomination details. Business names, ABNs, addresses and nominated positions that are identical across every application the sponsor makes.
Identity fields (names, dates of birth, passport details) are quick to type but are where a transposition does the most damage, so they are worth prefilling for accuracy rather than speed. Narrative fields, such as statements and explanations, should be written by a person, pasted in deliberately and read back in context.
What an auto-fill tool must never do
Four lines. A tool that crosses any of them does not belong in a registered practice.
- It must not submit. Reviewing the summary, making the declarations and clicking Submit are the agent's acts. An extension that lodges on its own has made declarations nobody read.
- It must not log in or hold your credentials. You open ImmiAccount yourself, with your own multi-factor authentication. The tool works inside a session you started and can see.
- It must not guess. An empty field is a question for you. A plausible-looking wrong answer is a false statement with your name on it.
- It must not operate out of sight. The fill happens on the page you are looking at, when you ask for it. Nothing runs in the background, nothing is queued and nothing happens on a page you have not opened.
The stakes are the usual ones, borne by the client first. Public Interest Criterion 4020 allows refusal where false or misleading information is given in an application, with a three-year bar on most further visas; a visa already granted can be cancelled under section 109 of the Migration Act for incorrect information. For the agent, the Code of Conduct prohibits false or misleading statements (section 15), extends that prohibition to documents given to government officials (section 20) and requires every piece of immigration assistance to be given competently and diligently (section 13). Prefill shifts none of this. Every answer on the form remains yours and your client's.
ImmiAccount is the Department's system, and its terms and conditions are an agreement between the account holder and the Department. Read them yourself before adopting any tool, and again when they change. The model we build to is prefill in your own logged-in session, under your control, with a person reviewing every page and lodging personally. Anything that acts in ImmiAccount without a human present is a different product and a different conversation.
A review protocol that holds up
Before you fill
- The questionnaire is complete and the client has confirmed it. A half-finished questionnaire produces a half-filled form and a false sense of progress.
- Identity has been verified (section 36 of the Code), and the passport details, dates and names on the file match the documents, not the client's memory.
- The matter carries the right subclass and stream, because the mapping follows the form you open.
While you fill
- Fill one page, then read it against the source documents before moving on. Names, dates of birth, passport numbers and expiry dates get checked character by character.
- Watch the fields that forms handle differently: dropdowns with a near-match, dates in another format, "Other" categories, and Yes/No questions where the answer depends on a definition.
- Treat every blank as a question. Answer it from the file, or stop and ask the client, and record the answer in the questionnaire so the next form gets it too.
Before you submit
- Review the application summary in full, as the Department presents it, not as your system does.
- Make the declarations yourself. If a colleague prepared the application, the reviewing agent reads the summary before anyone clicks Submit. Our pre-lodgment quality assurance guide sets out a sign-off that works in a team.
- Save the submitted application summary and the acknowledgement to the matter, record the transaction reference number, and write the file note. The retention clock on the file runs from the last action, and the lodgment is one.
Security questions to ask any auto-fill vendor
- Which sites can it run on? The answer should be the lodgment sites and your own case management domain, and nothing else. Browser extensions declare this in their manifest, and a store listing shows it before you install.
- Where does the data go? Between your browser and your own account. No analytics, no third-party scripts, no vendor server in the middle collecting field values.
- Does it do anything in the background? No. It should act only when you click, only on the page you are viewing.
- How is it updated? Through the browser's store, with a version history you can read. Files you install by hand are a maintenance and security risk.
- What happens on uninstall? Any cached client data should be cleared from the browser.
- Does it work with multi-factor authentication? The Department introduced MFA for ImmiAccount in 2025. A prefill tool works inside a session you authenticated; anything that wants your credentials so it can log in for you is asking for too much. Our MFA guide covers the account side.
For the record: the LodgeHQ eLodge extension is published on the Chrome Web Store, runs only on the sites it fills (ImmiAccount, SkillSelect, the VETASSESS portal and the AFP National Police Check site), exchanges data only with your own LodgeHQ account, acts only when you click, and clears its cache when removed.
Beyond ImmiAccount
The same structured data serves the other portals a skilled matter touches. SkillSelect expressions of interest, VETASSESS skills assessment applications and AFP National Police Check applications all ask for the same personal particulars, addresses and employment history, and the LodgeHQ extension prefills those too. For the Department's paper forms, LodgeHQ generates 37 pre-filled Department PDFs plus the ART's MR5 from the same questionnaire, leaving blank anything the data cannot answer with certainty.
If your practice shares an organisation ImmiAccount across several people, the account structure and permissions deserve as much attention as the fill. Our ImmiAccount workflow guide covers organisation accounts, team access and the discipline around attachments and payments.
Measuring the gain without inventing numbers
Resist the vendor's number and produce your own. Take one application type you lodge often. Time the data entry for the next one without prefill and the one after with it, from opening the form to reaching the summary page. Count the corrections the reviewing agent makes at the summary stage in each case. Two matters are not a study, but they are your numbers, from your questionnaires, and they will tell you where the questionnaire needs tightening, which is usually where the real gain is.
The bottom line
ImmiAccount auto-fill, done properly, is the removal of the second typing: verified facts flow from the questionnaire to the Department's form while the agent reads every page and lodges personally. It must not submit, must not hold your login, must not guess and must not act out of sight. Inside those lines it turns the longest, least valuable part of a lodgment into a review task, and makes the file, not the form, the place where the facts live. The LodgeHQ eLodge extension is included in every LodgeHQ subscription, and you can try it on a 14-day free trial alongside the questionnaires that feed it. For the full picture of what practice software should do around the lodgment, see our complete guide to migration practice management software.