TP Documentation Automation: From Spreadsheet to Living Document

The classic transfer pricing documentation process is a copy process: the benchmarking work lives in a database search and a set of Excel screens, and the documentation is assembled by copying — the comparables table, the range, the tested party numbers — into a word processor, where it becomes a snapshot that starts to drift from the working file the moment the work continues. Documentation automation inverts the direction: the study is the source of truth and the document is generated from it, so the Local File, the benchmarking annex and the working file are the same numbers by construction. This guide is the mechanism — what “generated from the study” means per document block, the roll-forward across years, the versioning, and the review workflow — and the boundary where the professional’s review still sits.

The direction of truth

The copy process (today, typical)	The generated process (the target)
The working file is the database + Excel screens	The working file is the study — structured, parameterized, in the system
The documentation is assembled by copying values into a document	The documentation is generated from the study’s fields
A change after assembly (a comparable dropped, a threshold moved) requires finding every place the value appears	A change re-runs the affected computation; the document is regenerated from the changed study
The annex and the working file diverge silently — discovered, if at all, at audit	The annex is the working file’s output; divergence is not possible without a recorded override
“Contemporaneous” is asserted from the file dates	Contemporaneity is the workflow’s property — the document is produced as the study is completed

The property worth having is not the generation itself — it is that the document cannot say something the study does not support. Every number in the generated Local File traces to a study field; every override (a comparable kept or dropped against the screen’s recommendation) is in the record and appears in the document with its reason. The documentation weaknesses that trigger audits — the annex that doesn’t reconcile, the range that doesn’t match the table, the method rationale that doesn’t match the method used — are, in the generated model, classes of error that do not exist, not errors that are checked for.

Per document block: what is generated and what is reviewed

The Local File structure (Rule 10D) and the Master File block by block:

Block	Generated from the study	The professional’s role
Profile / group structure	The entity profile as captured (name, jurisdiction, activity, the FAR summary)	The accuracy of the profile — what the entity actually does, not what it is described as
Functions, assets, risks	The FAR profile data (the structured functions/assets/risks, the comparability drivers)	The FAR analysis itself — the judgement on what the entity really performs and owns (see functional analysis)
Method & PLI rationale	The method as applied, the PLI, the comparability facts the choice rests on	The rationale prose — why this method is the best method for these facts (see how to choose a method)
Tested party selection	The two profiles side by side, the complexity comparison as recorded	The selection decision and its reasoning (see tested party selection)
Benchmarking annex	The search design, the filter sequence with the per-company results, the qualitative decisions with reasons, the adjustments with method and inputs, the range with its derivation	The review of the annex against the defence standard — the accept-reject defense pass
The tested party position	The tested party PLI, its position in the range, the conclusion (inside / outside, the adjustment if any)	The conclusion — and, where the position is outside the range, the analysis that follows it
Related party transactions	The transaction list as captured, per transaction type, with the amounts	The completeness and classification of the list (the s.92(2) coverage)
Narrative sections	First-pass prose generated from the study fields	The rewrite — the professional’s voice, the firm’s methodology stated, the jurisdiction-specific positions

The split is consistent: the data and the derivation are generated; the judgement and its prose are the professional’s. The document is “automated” in the same sense the benchmarking is — the mechanical layer runs, the judgement layer is recorded on top (see benchmarking automation for the study-side map, and AI in transfer pricing for the control standard on the generated prose).

Roll-forward: the year-to-year problem

The documentation work is annual, and the annual problem is the roll-forward — last year’s Local File is 70% of this year’s, and the 30% that changes (the numbers, the comparables set, the transactions, the profile) is exactly where the errors are. The spreadsheet process handles the roll-forward by copying last year’s document and editing; the drift enters at every copied block that was not edited carefully.

The generated process handles it structurally:

1. The study rolls forward, not the document. This year’s study starts from the tested party profile and the methodology (the firm settings), pulls the current-year data, and re-runs the search and screens against the current database. Last year’s study remains the prior-year record.
2. The comparison is explicit. The year-over-year view — the range then vs now, the set then vs now (which comparables entered, left, changed), the tested party position then vs now — is a generated artefact. It is the block the TPO reads first in a follow-up year, and in the generated model it is accurate by construction rather than carefully maintained.
3. The multi-year data rolls with the study. Where the method uses three-year data, the averaging is computed over the recorded periods with the recorded method — the roll-forward adds a period to the computation, it does not re-key a table.
4. The document is regenerated, then reviewed. The professional reviews the change-set (what moved, why), not the whole document — the unchanged blocks are unchanged because they are generated from unchanged inputs.

The discipline this enforces is the one the compliance calendar assumes without stating: the documentation for year N is produced from year N’s work, contemporaneously, with year N−1’s document as the structural reference — not as the editing base.

Versioning and the review workflow

The generated document enters the same review states as the study:

• Draft — the generated first pass, complete but unreviewed. Any user can see it; it carries the draft state, and no downstream use is allowed from it.
• Review — the professional’s pass: the narrative rewrite, the annex check against the defence standard, the completeness of the transaction list. Edits at this stage are recorded edits — who changed what, against which generated version.
• Sign-off — the partner’s act. The signed version is pinned: the study state it was generated from, the review edits applied, the signer, the time. A later change to the study produces a new version, it does not silently move the signed one.
• Archive — the signed version as the record for the year. The audit trail of the study — the screens, the overrides, the reviews — archives with it, so the filed document and its evidence remain a pair.

Two properties the versioning must hold, because the authorities check both:

1. The filed version is retrievable, exactly. Not “the current version of the file,” the filed version — with the study state it was generated from. Where the study changed after sign-off (a comparable dropped for the next year, a parameter corrected), the filed version still shows the numbers that were filed.
2. The evidence pair is intact. The document and the study record that produced it — the screens, the per-company evidence, the override rationales — move together. A Local File without its accept/reject record is a document the audit defense cannot support, and the generated model’s job is to make that pair impossible to separate.

Cross-document consistency (Local File, Master File, CbCR)

The three-tier documentation (the structure guide) has a standing failure: the same fact stated three times, three slightly different ways — the group structure in the Master File that doesn’t match the entity list in the Local File, the revenue in the CbCR that doesn’t match the transaction totals. The generated model addresses the two tiers it owns:

• The Local File and the benchmarking annex are one document generated from one study — the internal consistency is structural.
• The Local File and the Master File share the captured profile: the entity’s activity, the FAR summary, the related party list. Where the Master File block is generated from the same capture, the two documents cannot disagree on the profile — they can still disagree on the analysis, which is the professional’s to keep consistent.
• The CbCR is generated from the consolidation, not from the study — the reconciliation between the two (the jurisdictional totals vs the transaction detail) remains a check, not a generation. The CbCR guide covers the data-quality risks; in the generated model the Local File side of that reconciliation is at least accurate.

The honest boundary: generation removes the transcription errors across the tiers (the copied value that was not updated); it does not remove the analysis inconsistencies (the two documents giving two different explanations of the same fact). The latter is a review standard — cross-document consistency is on the reviewer’s checklist, and the generated model makes the checklist shorter, not empty.

FAQ

Does generated documentation satisfy “contemporaneous” for penalty protection? It helps the standard, not replaces it. Contemporaneity (the penalty protection logic) is about the documentation being prepared as the transactions happen, on the data of the year — and the generated model is structurally contemporaneous: the document is produced from the study as the study is completed, from the year’s data, in the year’s workflow. It is still the firm’s duty to run the workflow in time for the deadline; the calendar, not the generator, is what misses it (see the compliance calendar).

What happens to our existing documents (the prior years, the word-processed files)? They remain the historical record — the filed versions of prior years are not regenerated. The generated process starts with the current year: the study is built (the prior year’s document as the structural reference for the roll-forward), and the current year’s document is generated from it. The transition year is typically the one where the team keeps the old template for the narrative sections and generates the data blocks — the hybrid is the practical first step.

Can the reviewer edit the generated document freely? The reviewer edits the narrative (the prose sections) and records overrides on the data (a comparable’s status, a parameter) against the study — the data blocks are not hand-edited in the document, they are changed in the study and regenerated. Hand-editing a generated data block is the exact re-introduction of the copy process: the block now says something the study does not support, and the next regeneration (or the next audit) finds the difference.

Is the Master File as well as the Local File a candidate for generation? The Local File first — it is the document that carries the benchmarking, and it is the one the TPO examines. The Master File’s generated blocks are the profile and group-structure sections (from the same capture); its narrative (the group’s intangibles, the financial transactions, the TP policy) is the professional’s writing, supported by the captured data. The CbCR sits alongside, from the consolidation — the three-tier set, with the Local File as the generated core.