XTK placeholder reference (complete list)

This is the complete reference for XTK placeholders — every token you can type into a document template and have XTK fill from a client's live details in Xero Practice Manager (XPM). It covers the client, contact, address, custom-field and date tokens, the :LASTn modifier, and the [IF …] … [ENDIF] conditional blocks, each with sample output.

XTK is an independent product and is not affiliated with or endorsed by Xero Limited.

How placeholders work

A placeholder is a NAMESPACE:FIELD name in square brackets, typed straight into your Word document — [CLIENT:NAME], [CONTACT:PRIMARY:EMAIL], [DATE]. When someone generates a document from the template, XTK scans it for tokens, pre-fills each one from the client's details in a fill dialog you review, and stamps the confirmed values into a new .docx. Three rules cover the whole grammar:

• Tokens are uppercase. [CLIENT:NAME] is recognised; [client:name] is left as ordinary text.
• Each distinct token becomes one editable field in the fill dialog, however many times it appears in the document — and every pre-filled value can be overridden before you generate.
• Anything XTK can't fill stays put. Unknown tokens, plain bracketed prose like [see note], and fields you leave empty all render as their literal text. Generation never fails because of a placeholder.

Placeholders work anywhere Word puts visible text — the document body, headers and footers. And it doesn't matter if Word has invisibly split a token into pieces while you were typing or formatting: XTK reads each paragraph as a whole, so tokens always resolve.

Client details — [CLIENT:FIELD]

The CLIENT namespace reads the record of the client you're generating for. Names and identity first:

Email, phone and web

Business and tax

Practice fields

Addresses — [CLIENT:TYPE:FIELD]

Addresses use a three-part token: which address, then which piece of it. Pick a type…

…and combine it with any of the six fields:

So [CLIENT:POSTAL:POSTCODE] is the postal address's postcode, and a full address block in a letter looks like this:

Contacts — [CONTACT:SELECTOR:FIELD]

The CONTACT namespace reads the client's contact people. It's also a three-part token: pick a contact, then a field.

Custom fields — [CUSTOM:FIELD NAME]

Any custom field your practice has defined in XPM can be referenced by name: [CUSTOM:GST Period] fills the “GST Period” field's value for this client. Matching is forgiving — case doesn't matter, and underscores read as spaces, so [CUSTOM:GST_PERIOD] finds the same field. The value is rendered exactly as stored; a field with no value for this client is left for you in the fill dialog.

Dates — [DATE] and formats

[DATE] fills today's date, computed on your clock at the moment you generate the document, written out in full — for example 9 June 2026. Like everything else it lands in the fill dialog first, so you can override it when a letter needs a different date.

Add a colon and a pattern to control the format. A pattern mixes these tokens (shown for 9 June 2026) with any separators you like — slashes, dashes, dots and spaces pass through as-is:

Formatting stored dates

The client's stored dates — [CLIENT:DATEOFBIRTH] and [CLIENT:DATEOFDEATH] — render as dd/MM/yyyy by default and take the same patterns: [CLIENT:DATEOFBIRTH:d MMMM yyyy] gives 15 January 1990. They're read date-only, so a birthday never shifts a day because of timezones. Stored dates take a date format, not the :LASTn modifier below.

Last characters — the :LASTn modifier

Append :LAST and a number to any text placeholder to render only the last few characters. The classic use is quoting a tax number without printing all of it: if the stored number is 123456789, then [CLIENT:TAXNUMBER:LAST4] renders 6789.

• It counts characters, not digits — spaces stored in the value count too.
• The output is plain text, not a mask: it renders 6789, not *****6789. Put your own “ending in” wording around it.
• A value shorter than n renders whole.
• It works on any text field — client, contact, address or custom — but not on the stored-date fields, which take a date format instead.

Conditional blocks — [IF …] … [ENDIF]

Wrap a passage between [IF condition] and [ENDIF] and it's kept or dropped per client when the document is generated. Conditions come in exactly three shapes:

• Comparisons ignore case and surrounding spaces, and the quotes are optional (single or double both work).
• The field a condition tests shows up as an ordinary field in the fill dialog, so the condition acts on the value you see and confirm.
• A kept block loses just its two markers; a dropped block vanishes entirely — markers, content and any paragraphs in between, with no blank lines left behind.
• Blocks nest inside each other, which is how you get an AND. There is no AND/OR syntax and no [ELSE] — for either/or text, write two back-to-back blocks, one with = and one with !=.
• An unmatched marker — an [IF] with no [ENDIF], or a stray [ENDIF] — is left as literal text in the output, which makes the mistake easy to spot.
• Keep both markers in ordinary paragraphs; splitting a block across table cells in Word isn't supported.

For a worked example — an Australian-only GST paragraph in an engagement letter — see the document templates guide.

Where next

The document templates guide walks through uploading a template and generating a letter from it, with these tokens doing the filling. Folder templates use the same [DATE] tokens inside folder names, so a standard client folder structure can stamp itself with the right year as it's created.