Transfer Pricing Documentation Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the project get scoped as document production when the work is data assembly?

The brief almost always says the same thing. We need a system that produces local files. Vendors and developers then demonstrate template libraries, section editors and export formats, because that is the part everybody in the room can picture. Nobody demonstrates mapping three charts of accounts to one tested party segmentation with effective dates, because it does not look like anything.

This is specific to transfer pricing because the deliverable is a Word document. In most finance systems the output is a number and the quality of the number is visible. Here the output is a narrative wrapped around a number, and a beautifully formatted local file containing a segmented margin your team assembled by hand in a workbook looks identical to one the system produced. Six months after go live the head of tax discovers the cycle still costs what it cost, because the four weeks of drafting were never the four months of pain.

The fix is an acceptance test written before the statement of work is signed. Pick your three hardest entities, usually one acquired business on its own ledger, one where local generally accepted accounting principles differ from group, and one where shared costs are allocated on a contested key. Require the system to produce their segmented profit and loss from source data with no human touching a spreadsheet, and require it to match what you filed. Put a date on it. If a developer resists putting that test in writing, they are quoting a document generator.

What goes wrong when you migrate prior year files and allocation keys?

The archive that has to come across is not a database. It is a folder of prior year local files in Word, a set of workbooks named after people who have moved on, benchmarking reports from an adviser as PDFs, and a functional analysis written in prose. Teams budget migration as an import and discover it is a conversion.

Two things reliably go wrong. First, converting a functional analysis paragraph into structured facts per entity is judgement work that only your tax team can do, and it consumes their hours at exactly the moment they are also running a live compliance cycle. Second, the allocation keys turn out not to be keys at all. A tab contains hard coded percentages that somebody derived from headcount in a year nobody can name, and reverse engineering them means asking questions the current team cannot answer. Groups routinely discover during this exercise that last year's numbers cannot be reproduced from last year's inputs.

The fix is to scope conversion narrowly and prove it early. Convert three entities completely, reproduce their filed figures, and only then decide how far back to go. Two prior years is usually enough for the audit window that matters; older files stay as attached documents rather than structured facts. Budget the conversion in tax team days on the plan, visible to whoever approves the project, because it is the line that gets quietly absorbed and then blows the timeline.

Why do the ERP and consolidation feeds break after launch?

Everything works in month one because somebody checked it. Then the chart of accounts gains four new cost centres at year end. An acquired entity migrates onto a different ledger. A controller renames a profit centre for a local reporting reason. In each case the extraction still runs, the file still lands, the trial balance still balances, and amounts quietly stop reaching the tested party segment they belong to.

This breaks harder in transfer pricing than in most finance systems because of the cadence. A treasury feed that fails is noticed the next morning. A transfer pricing feed that drifts in February is noticed in September, when nineteen local files are due and the segmented margin for a tested party has moved four points for reasons nobody can explain. By then the year is closed and the only remedy is an explanation.

Three things prevent it. The mapping layer has to be editable by tax rather than by IT, with effective dates, so a mid year restructuring does not corrupt the comparison retrospectively. A completeness run has to execute monthly and alert on any source account that is not mapped, in the week it appears rather than at year end. And source extracts have to be snapshotted immutably at the moment they are taken, so a later restatement in the ledger cannot silently change a year you have already filed. That last point is the one developers skip, and it is the one your adviser will ask about during an audit.

What happens when jurisdiction specific local file requirements are not covered?

The three tiered structure from BEPS Action 13 gave every country a master file, a local file and a country by country report, and then every country implemented it differently. Content requirements vary. Several jurisdictions require local language. Deadlines sit at different points relative to the tax return. Some demand specific schedules or a signed declaration. Build one template with a country field and you produce nineteen documents that are each slightly wrong.

The penalty exposure is the smaller half of this. The larger half is inconsistency. When an examiner in one country reads a functional description and it does not match the description of the same entity filed next door, that discrepancy becomes the opening question, and answering it costs far more than the drafting ever did. A single template guarantees the descriptions match. A per country template with no shared fact layer guarantees they do not.

The fix is to hold facts once and generate documents from them. Entity descriptions, functional analyses, transaction inventories, financial data and benchmark conclusions live as structured content. Each jurisdiction gets a template that assembles those facts into its required sections, in its required language. Assign an owner per jurisdiction who signs off the template rather than the document, so the review happens once a year instead of once a file. Then build a consistency report that flags where the same fact renders differently across files, and run it before filing rather than after an examiner runs it for you.

Should you build custom or configure what you already own?

For a large number of groups the honest answer is do not build. If you have five entities on one enterprise resource planning system, three local files and stable intercompany arrangements, Thomson Reuters ONESOURCE Transfer Pricing or Exactera will produce compliant documentation for a fraction of a build, and their drafting automation genuinely works. If your data is reasonably centralised and your actual gap is in year monitoring rather than document production, Aibidia is built for that and buying it is the sensible move.

There is a single diagnostic that settles it. Ask your team what share of the cycle is spent assembling numbers versus judging them. If judgement dominates, your bottleneck is analysis and better drafting tools will help. If assembly dominates, no documentation product will move the number, because the assembly problem lives upstream in your ledgers and none of these tools own that.

Build when at least two of these are true. Your finance data sits in three or more systems that were never harmonised, which is normal for any group that has acquired anything. Your allocation keys and segmentation logic are bespoke and held by one or two people. You need in year margin monitoring on your own reporting calendar. Or you have a live audit or advance pricing arrangement where reproducing a prior year exactly is worth real money. A common and sensible pattern is keeping the documentation product for drafting and building only the data layer beneath it.

How do hidden costs get into the quote?

Five of them, and they arrive in a predictable order. The first is source systems. A quote written against two enterprise resource planning systems does not survive the discovery that a division acquired last year still runs its own ledger, because each additional source is a separate extraction, mapping and reconciliation effort rather than a configuration change. Price each one as a named line item.

The second is the tax team hours for converting prior year narrative, which sits in nobody's budget because it is not developer time. The third is benchmarking. Somebody will propose building a comparables database, and it will sound like a natural extension. It is not. Comparables should stay with your advisers or your existing subscription, with the system storing the accepted set, the search strategy, the rejection reasons and the resulting range as evidence.

The fourth is reproducibility, meaning versioned mappings, versioned allocation rules and immutable snapshots. It is invisible in a demo, it adds real weeks, and it is the single capability that pays for itself the first time an authority asks how a figure was produced. The fifth is the local controller portal, which sounds small and becomes user management, permissions, translation and training. Defer the portal, fund the reproducibility, and put the number of source systems on the front page of the quote.

What separates a build that works from one that fails here?

The builds that work are the ones where the acceptance criterion is reproduction rather than production. Ask any candidate developer to describe how a prior year is regenerated exactly. You want to hear versioned mappings, versioned allocation rules and immutable source snapshots, without prompting. A team that answers by describing document templates has built a publishing system before and not a tax system.

Ask who edits the mapping after go live. The answer must be your tax team. If mapping changes require a developer ticket, the system becomes stale within two cycles and people quietly go back to workbooks. Ask what happens to a non reconciling extract: it should quarantine and alert, never partially load. Ask about benchmarking and listen for a developer who says it stays with your advisers.

On numbers, the shape that holds is a first release covering entity and transaction registers, ledger ingestion, the mapping and allocation layer, segmented profit and loss and local file production at $80,000 to $160,000 over 12 to 18 weeks, with a full platform adding country by country reporting, agreement tracking and in year monitoring at $220,000 to $500,000 over 8 to 14 months. Then run one full cycle in parallel with your existing process. The differences you find in that cycle are the requirements you missed, and finding them yourself costs less than finding them in an examination.