TFNs and Director IDs with XPM
StructureGram and XPM both hold sensitive identifiers, but they do not exchange them symmetrically. This page explains what moves where, and why.
Summary
| Identifier | StructureGram → XPM | XPM → StructureGram |
|---|---|---|
| Tax File Number (TFN) | Sent, when valid and XPM has none | Never — XPM does not return it |
| Director ID (DIN) | Not possible | Not possible |
Tax File Numbers
StructureGram can fill a gap in XPM
When you push or sync a client, StructureGram sends the TFN it holds if both of the following are true:
- The TFN passes the ATO check digit. XPM rejects a record carrying a TFN that fails its own validation, which would block the whole client update — so an invalid TFN is left out and reported rather than risking the rest of the save.
- XPM does not already have a TFN for that client. StructureGram fills gaps; it never overwrites a TFN your practice already recorded in XPM.
If StructureGram cannot read XPM's current value for a client, it treats that as "XPM may already have one" and sends nothing. It only ever writes into a field it has confirmed is empty.
StructureGram cannot read a TFN back from XPM
XPM stores a full TFN but returns it masked to the last 3 digits — for
example ******782. There is no full value in the response to import, under any
setting or permission we can request through the API.
This has three consequences worth knowing:
- A TFN in XPM will never appear in StructureGram. If you need a TFN in StructureGram, enter it there. See Entering sensitive data.
- Reconciliation only offers to send a TFN, never to bring one in. If XPM has a TFN and StructureGram does not, no difference is raised — there would be nothing to apply.
- Matching TFNs are recognised. Reconciliation compares the last 3 digits on both sides, so a client whose TFN you already pushed shows no difference on later reviews.
What you see in a review
A TFN difference appears in two situations:
- StructureGram holds a TFN and XPM does not. Applying the item pushes the full StructureGram TFN into the gap.
- Both sides hold a TFN and the last 3 digits disagree. This appears as its own review item with two explicit choices: keep the XPM value (nothing is written) or replace it with the full TFN stored in StructureGram. Replacing sends only the TFN — no other fields ride along with it.
StructureGram's side displays as a masked tail (••• ••• 782) because only the
last 3 digits are held in readable form; XPM's side shows what XPM reveals,
which may itself be masked to the last 3 digits.
A kept mismatch reappears on the next review — by design. Choosing to keep XPM's value means "don't change XPM now", not "the systems agree": the discrepancy still exists, and XPM's masking means StructureGram cannot verify which side is correct. Rather than hide a known disagreement about a tax file number from whoever runs the next review, the item is raised again until the values genuinely match — either correct the TFN in StructureGram (once the last 3 digits agree the item disappears) or replace the value in XPM.
If the TFN fails the check digit, the push reports it as omitted with a reason naming only the last 3 digits, and the item is not marked as applied.
Director IDs
A DIN cannot move in either direction, and this is not a setting.
XPM's client API does not include a DIN field at all. A client with a Director ID entered in the XPM screen returns exactly the same set of fields as one without it. The Director ID is real in the XPM interface and in XPM's file import — it is simply not part of the API StructureGram connects to.
Because of this:
- StructureGram never imports a DIN from XPM.
- StructureGram never sends a DIN to XPM. Writes naming a Director ID field are accepted by XPM and silently discarded, so an apparent success would be misleading.
- No DIN difference is ever raised during reconciliation, in either direction.
Record Director IDs in StructureGram, and in XPM separately if your practice needs them there.
Frequently asked
Why is there no setting to control TFN import?
There used to be one, and it was removed. It offered to prevent an import that could never happen, which made it look like a privacy control while protecting nothing. TFNs have never travelled from XPM into StructureGram.
Can a permission change let StructureGram read TFNs from XPM?
XPM has a staff-level privilege controlling who can view client TFNs in its own screens. That governs the XPM interface. The masking StructureGram receives is a property of the API response, and no scope available to the integration returns the full value.
Will pushing a TFN overwrite what my practice recorded in XPM?
No. StructureGram only sends a TFN when XPM's field is empty.