Offer letter variables HR should standardize

Offer letter variables are named placeholders — candidate name, role, CTC or pay structure, joining date, location — filled from the hiring record when you generate a letter. They exist so recruiters do not retype numbers into a fresh document every time. This page owns those tokens. It is not a library of legal clauses or appointment-letter statute. Stage-by-stage hiring operations stay on the recruitment hiring checklist. The packet after accept stays on the offer-to-onboarding handoff article. Product surfaces: Dayzen recruitment (offer templates with dynamic tokens) and Dayzen onboarding (work after the facts are locked). This page is not a second legal letter type.

When CTC is pasted by hand, joining dates drift by a week, and names follow the CV nickname instead of the offer identity, onboarding and payroll inherit typos. Tokens do not make the offer “more legal.” They make the letter match the record you already decided to offer.

A variable is a field with one source

A useful token has three properties:

1. A stable name in the template (the placeholder staff recognise).
2. A single source field on the job, application, or offer record — not “whatever is in the last email.”
3. A rule for blanks — the letter will not generate, or it will show an obvious gap, rather than silently omitting a sentence.

If two people can type the same fact in two places, you do not have a variable. You have a race. Put CTC on the offer (or the approved requisition band you copy onto the offer). Put joining date on the offer. Put legal name on the candidate identity you will search later. The template only prints those fields. It should not be a third place to invent a salary.

Dayzen recruitment includes offer templates with dynamic tokens for this reason: the letter is a view of the hiring record, not a parallel Word file that becomes the truth. If someone edits the PDF after generation and does not update the record, you have split the facts again. Prefer regenerating from the record after a genuine change (new date, revised CTC with approval) over red-pen edits that never flow back.

The small set most Indian SME offers actually need

Do not start with forty tokens. Start with the facts that, if wrong, create a painful joining:

• Legal name — as you will put on the employee record, not the email display name.
• Role / designation — the internal title the offer commits, mapped from the job, not the posting slogan.
• Department and reporting manager — if you state them in the letter; if you do not state them, do not pretend a token exists.
• Work location or remote pattern — the one you will use for attendance and later payroll location, not a poetic “anywhere.”
• Employment type — full-time, intern, contract, as you actually classify, if the letter names it.
• CTC or the structure you showed — annual figure and, if the template includes a break-up, the same break-up fields as the record.
• Joining date — one calendar date.
• Offer date and, if you use one, offer expiry date — so “open until whenever” is not the default.
• Entity / employer name — the company that is actually hiring, when you have more than one.

Optional tokens that still earn their keep: probation length as your policy states it (this is not a nationwide legal constant on this page), notice period as written in your template, and a requisition or offer ID so later people can find the file. Do not add tokens for every policy paragraph. Policy text is static template language. Variables are the facts that change per person.

This page does not draft those static clauses. If your counsel owns wording on confidentiality, IP, or termination, they own it in the template body. Tokens should not be used to smuggle legal conclusions (“as required by Indian law”) into a merge field. Keep statute out of the placeholder list.

Why manual retyping fails in the same three places

Name mismatches: the CV says “A. Sharma,” the application form says “Ankit Sharma,” and the offer says “Ankit kumar Sharma.” Payroll and bank letters then argue. Source the name from the identity you verified for the offer, and print that token only.

Number mismatches: a recruiter types 12.5 LPA in the letter while the approved note said 12 LPA, or they include variable pay in monthly language. Source CTC from the approved offer fields. If variable is part of the deal, it needs its own labelled fields so a token cannot quietly add it into basic. Dayzen payroll will calculate later from the employee structure. The offer’s job is that the printed total matches what you approved — not that recruitment runs payroll.

Date mismatches: verbal “first Monday of next month,” a calendar hold, and a letter with last month’s date reused from the previous hire. Joining date is a field. If it slips after the letter went out, update the record and regenerate or issue a written revision both sides file. Do not ask onboarding to guess which date is real. The handoff article owns packing that date into the activation packet; this page owns not typing it twice by hand in the first place.

Template versus letter versus record

Keep three objects distinct:

1. The template — boilerplate plus token names. Version it. When you change a clause, you change the template, not one lucky PDF.
2. The offer record — this candidate, this job, these values, this status (draft, sent, accepted, declined, expired).
3. The generated letter — a snapshot of template version plus values at send time. Keep that snapshot. If values change, you have a new snapshot, not a silent overwrite of history.

Teams that only keep the latest PDF cannot answer “what did we send on Tuesday.” Teams that only keep the record and never freeze a snapshot cannot show the candidate what they received. You want both: current fields for operations, and the file that went out.

The hiring checklist still owns who may approve compensation and who may send. This article does not retell that ladder. It requires that approved values are what the tokens read. An unapproved number in a preview is not an offer. A draft should not be mailable as final.

Blanks, defaults, and dangerous fallbacks

Decide what happens when a token has no value:

• Hard stop for legal name, designation, CTC (or structure), joining date, employer name. Do not send a letter with those empty.
• Omit the sentence for optional lines (reporting manager if you sometimes omit it).
• Never default CTC or joining date from the previous candidate. Defaults that copy the last hire are how you send someone else’s package.

Placeholder text left in the output (“{{joining_date}}”) is embarrassing but recoverable. A silently skipped compensation paragraph is worse: the candidate thinks something was promised in the call, and the file disagrees. Prefer obvious failure over pretty incompleteness.

Watch formatting. CTC should print in the units you always use (lakhs, rupees, with or without commas — pick one in the template). Dates should print in one convention. Location should print the office name you use in the directory, not a pin code one recruiter invented. Tokens do not fix messy source data; they amplify it. Clean the field before generate.

What onboarding needs from the same tokens

After accept, activation should not re-key name, role, CTC, and joining date from a screenshot. The offer record is the source for those four. Dayzen onboarding is the work after that packet is accepted — new-joiner pipeline, forms, activation — not a second place to invent CTC. If finance must still attach a cost centre, that is an open item, not a blank compensation token.

Do not treat tokenised offers as pre-onboarding forms. A form collects bank and identity details the joiner types; a letter prints the deal. Mixing them produces letters that ask for IFSC and forms that restate CTC. The hire-to-activate guide owns the path after accept; this page stops at a letter whose variables match the deal.

Revisions without losing the trail

Offers change. The candidate asks for a week. Compensation is re-approved. Location flips to another office. Process:

1. Update the offer record fields (the sources).
2. Record who approved the change, if your checklist requires it.
3. Generate a new letter from the current template version plus new values.
4. Mark the previous letter superseded; do not delete it.
5. Send the new file through the same channel you treat as official.

Editing a clause “just this once” in Word, while leaving tokens pointing at old values, trains the organisation to distrust the system. If a one-off exception is real, either add a controlled free-text field with an owner, or change the template for everyone. A snowflake PDF is how two hires in the same week receive different probation sentences for no documented reason.

Failure modes

Symptom	Cause	Fix
Letter CTC ≠ approved note	Hand-typed letter, tokens unused	Generate from the offer record only
Wrong person name on bank form later	Nickname in the token source	Source legal name; freeze before send
Two joining dates in circulation	Side email after generate	Revise record, regenerate, supersede
Template still says last company’s entity	Static text treated as a variable	Entity is a field; update the source
Counsel asked for a clause library here	Wrong article	Keep legal body text in the template; this page is tokens

If a fact can be wrong in the letter while remaining “right” in the ATS, you do not have variables. You have decoration on a copy-paste workflow.

Standardise the names of the tokens so every recruiter means the same field. Keep Dayzen offer templates as the container that merges those fields. Use the hiring checklist for who may approve and send. Use onboarding for activation after accept. Do not turn this page into employment-letter taxonomy or legal drafting. The win is boring: the name, role, CTC, date, and location on the paper are the same values as the hiring record, every time, without a human retyping them.