TFN Generator: Test Data for Practice Systems

A TFN generator produces test strings for checking a form’s number rules. Use only approved synthetic fixtures in an isolated environment. A string that passes those rules proves neither ATO issuance nor the identity of the person entering it.

What a TFN Generator Can Tell You

A TFN generator makes number-shaped strings. It cannot issue a Tax File Number. Some strings can pass the expected format and the mathematical rule used to detect digit errors. That rule is often called a check digit test.

A passing result means the string meets the number rules your form applies. It does not establish that the ATO issued the number, that it belongs to a client or that the client’s identity is correct. A random TFN generator also cannot guarantee that its output is unallocated.

The ATO lists its TFN algorithm among the validation tools available to registered software providers. Use expected outcomes supplied with an approved fixture set, not a generator’s own claim that its output is valid.

If your client needs an issued number, direct them to the ATO’s TFN application route. The TFN application guide helps distinguish that task from testing a form. For the broader subject, use the TFN guide.

Prepare an Isolated Practice Test

Name the practice’s IT system-testing owner, the change being checked and the non-production environment in the test record. For example, a fictional test can check a changed TFN question and the messages sent when an answer needs correction.

Before entering a fixture, have these prerequisites ready:

• Permission from the practice and, where required, the software provider to test this environment.
• A provider-approved or practice-approved synthetic fixture set with expected outcomes.
• A disposable record containing fictional client details and no copied client documents.
• Email destinations and any mobile numbers controlled solely by the test team.
• Named test staff accounts with the access permissions you need to check.
• A plan for retaining redacted evidence and removing disposable records after review.

Check that the environment cannot send records, messages, exports or documents to real clients or production services. Disable production connections and use approved test destinations for any connection you need. If that separation cannot be established, stop before entering data.

The OAIC’s TFN handling guidance requires lawful handling and reasonable safeguards for real TFN information. Reusing a client’s TFN in testing creates exposure you can avoid with synthetic fixtures.

Use Approved Synthetic Fixtures

Obtain the fixture set from the software provider or your authorised testing owner. Record its version, approval, permitted environment and purpose. Keep the full test values in the approved test store. Use fixture labels in the test plan and evidence.

The labels below describe test cases. They are not values to paste into a TFN question.

Fixture label	Approved input description	Expected observation
RULE-PASS	A synthetic string approved to pass the supported number rules	The TFN number check accepts it
DIGIT-MISSING	An approved malformed string with one digit removed from a full-length case	The length check rejects it
CHARACTER-FAIL	A candidate containing a character the form does not support	The form identifies the unsupported character
RULE-FAIL	A string of supported length that fails the approved mathematical test	The TFN number check rejects it
BLANK	An empty answer	The form follows its documented required, optional or alternative-collection behaviour
SPECIAL-INPUT	A documented placeholder or special reporting code	The form follows its documented treatment for that code and context

Define DIGIT-MISSING against a documented invalid length. Removing one digit from a longer string does not establish that the remaining length is unsupported. Define RULE-FAIL from an independently approved expected result so the generator and form cannot endorse the same faulty calculation.

A TFN generator for testing can prepare candidate strings for your testing owner to approve and label. Keep those candidates inside the isolated fixture set. Never use a generated number in a live agency service or treat it as an issued TFN.

Special codes used in a reporting specification have meanings in that reporting context. A repeated-digit value copied from an example is not a universal test TFN. Record whether your form rejects it, treats it as a special answer or requires another collection path.

For real client work, follow your ABN and TFN checking procedure. Keep that procedure separate from this synthetic fixture exercise.

Test the Form From Entry to Review

Use the software’s documented actions in the approved environment. Record what happens at each checkpoint before moving to the next step.

1. Create the disposable fictional client record. Confirm that its contact destinations belong to the test team and its downstream connections are isolated.
2. Open its test form and enter RULE-PASS from the approved store. Observe acceptance by the TFN number check. Other missing answers can still prevent the whole form from being sent.
3. Enter each malformed fixture separately. Observe the expected rejection and a usable correction message. Check blank and placeholder inputs against their documented outcomes as separate cases.
4. Complete the remaining questions with fictional answers. Send the test form through its supported review procedure. Confirm that the form reaches the intended test staff.
5. Exercise a documented correction case in another answer. Inspect the test-only message, answer the correction as the fictional client and confirm that staff receive the corrected form.
6. Sign in through each relevant test staff role. Check that a hidden value stays hidden from staff without permission. For an authorised reveal, confirm that the software records the staff account and event as documented.
7. Inspect test emails, exports and generated documents. Search for unintended test-value exposure, including correction messages and attachments. Keep any evidence redacted before it leaves the approved test store.

For a fictional example, the test client enters RULE-PASS but omits a required document. The number check accepts the fixture. The separate missing-document check then requests a correction, which goes only to the test team’s destination.

That example checks whether the two decisions remain separate. A passing number rule must not erase an unrelated missing answer, and a correction message must not expose a hidden value.

Separate Tax Genie Checks From Identity

Tax Genie checks ABN, ACN and TFN format and checks other form answers for mistakes and missing information. Fixable issues go back to the client as a plain list. Only the affected sections reopen on the same private link.

Tax Genie removes every TFN before AI reviews the form. A TFN stays hidden until permitted signed-in staff reveal it, and every reveal is logged. TFNs stay out of emails, exports and generated documents. The TFN protection page explains this handling.

Use those outcomes when planning an approved Tax Genie test. The hidden value must remain unavailable to staff without reveal permission, and the correction message must identify the issue without including the TFN.

Neither a number-rule pass nor AI review confirms TFN issuance, ownership or identity. Keep the practice’s authorised identity-checking procedure separate. The OAIC explains the limits on using TFNs to confirm identity.

Verify the Results and Resolve Failures

The test passes when each approved fixture produces its expected rule result and the complete review path matches the documented behaviour. Only permitted staff can reveal a hidden value. For Tax Genie, no TFN value appears in test messages, exports or generated documents.

Use the first check below to investigate an unexpected result. Give the software provider redacted evidence, with fixture labels rather than full values.

Failure	First diagnostic check	Corrective action and evidence
A malformed fixture is accepted	Check whether the relevant rule is enabled and whether acceptance occurred before or after the documented checkpoint	Restore the intended setting or report the failed check. Include the fixture label, software version and accepted state
An approved passing fixture is rejected	Confirm the set is approved for this environment and input context. Check supported formatting and the expected result	Correct the input method or update the fixture approval. If rejection persists, provide the error text and reproduction steps
A hidden value reaches an unauthorised staff account or output	Check the account’s permission and identify the first screen, message or file containing the value	Stop that test path, restrict access to affected test output and notify the testing owner. Report the destination and redacted evidence
A blank or special-code case behaves unexpectedly	Compare the question’s settings with the documented optional, alternative-collection or reporting treatment	Correct the settings or raise a documented-behaviour defect. Include the case label and expected route

For an exposed value, inspect related test outputs before resuming. Correct the permission or output problem, then repeat the same case and its downstream checks.

Record the environment, software version, fixture labels, expected and actual outcomes and responsible reviewer. Mask values before taking screenshots, and omit them from reports. Close the test only when the reviewer can trace each result to its approved case and confirm that unintended destinations remain isolated.