TSA Pre-Signing Review
Build the catalog before you need it. Before you sign.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
A TSA service catalog is the line by line inventory of every service the seller will provide to the carved out business after closing, with each service’s scope, price, service level, dependencies, and exit date recorded against it. It is the single most important control document a buyer has during a transition, because everything the buyer pays for, manages, and exits is defined in it. A complete catalog is the foundation of any credible TSA exit strategy, and an incomplete one is where transitions quietly go wrong.
The service catalog is the inventory of every transition service in one place. Each entry names a service, describes what it includes and excludes, states its price and pricing basis, sets its service level, lists its dependencies, names an owner on each side, and gives an exit date. It turns a vague promise to keep the business running into a specific, priced, measurable, time boxed set of obligations.
Where the master TSA sets the rules and the schedules carry the legal detail, the catalog is the operational view the buyer actually manages from. It is the document the governance committee reviews, the migration team works against, and the finance team validates invoices with. If a service is not in the catalog, it is not being tracked, priced, or exited, which means it is either a gap or an uncontrolled cost.
A good catalog is built before signing, not assembled afterward from invoices. Buyers who wait until after close to discover what services they are actually receiving have already lost the leverage to scope, price, and time box them. The catalog is a pre signing deliverable, and the quality of the transition tracks the quality of the catalog.
Cost control ties back to the catalog. Each service has a price in it, so the buyer can validate that invoices match agreed pricing and that no service is being charged that was never agreed. Without the catalog, invoice validation becomes guesswork, and sellers are not always disciplined about charging only for what they deliver.
Performance control ties back to it. Each service has a service level in the catalog, so the buyer can hold the seller to a measurable standard and claim credits when the standard is missed. Exit control ties back to it as well, because each service has an exit date, and the migration plan is built by sequencing those exit dates against the buyer’s ability to stand up replacements.
Scope control ties back to it most of all. The catalog is the agreed boundary of what the seller provides. When the seller declines a request, the catalog settles whether the request was in scope. When the buyer assumes a service it is not receiving, the catalog reveals the gap. A complete catalog is the reference that resolves nearly every operational dispute during a transition.
There is a governance benefit as well. A shared catalog gives both sides one version of the truth to manage from, which keeps the monthly governance meeting focused on facts rather than recollection. The seller cannot quietly add a charge that is not in the catalog, and the buyer cannot demand a service that was never agreed. That single reference removes most of the friction that otherwise builds up over a transition, because the answer to almost every dispute is the same: check the catalog entry.
A complete catalog entry has, at minimum, a clear service name and description, an explicit scope boundary with inclusions and exclusions, a price and pricing basis, a service level with a measurement method, a list of dependencies, named owners on both sides, and an exit date with a termination mechanic. Each field exists to remove an ambiguity that would otherwise become a dispute.
The exclusions field is the one buyers most often skip and most often regret. A service described only by what it includes leaves its boundary open, and an open boundary is interpreted in favor of the party with less incentive to perform. Writing down what a service does not cover is what prevents both seller refusals and buyer assumptions.
The dependencies field is the one that protects the exit. Many services depend on other services, on third-party vendors, or on access the buyer takes for granted. Recording those dependencies lets the buyer sequence the exit so that retiring one service does not break another. A catalog without dependencies produces migration surprises that an hour of upfront work would have prevented.
The exit is executed against the catalog, service by service. The buyer migrates off a service, retires its catalog entry, stops paying for it, and moves to the next, sequencing the work using the dependencies and exit dates the catalog records. A live catalog that updates as services are retired gives the governance committee a real time picture of how much of the transition remains.
Without the catalog, the exit becomes a single, frightening event in which the buyer tries to leave everything at once because it never had a service by service view to migrate against. With the catalog, the exit becomes a managed sequence of small off ramps, each retired when its replacement is ready. This is the difference between a transition that ends on schedule and one that drifts into costly extensions.
The catalog also drives the conversation about stranded cost. As services are retired, the buyer can see which seller costs should fall away and hold the seller accountable when they do not. A catalog that records what each service costs is the evidence base for ensuring the transition actually reduces cost as it shrinks, rather than leaving the buyer paying for capacity it no longer uses.
The most common failure is incompleteness: services the business actually depends on never make it into the catalog, surface after close as undocumented dependencies, and get charged at whatever price the seller proposes after the fact. The cure is a thorough discovery before signing that maps every service the carved out business consumes, not just the obvious ones.
The second failure is vagueness: entries that name a service but do not bound it, price it precisely, or attach a real service level. Vague entries provide the comfort of a catalog with none of the protection, because every term is still open to interpretation. The cure is to insist on specific, complete entries and to send incomplete ones back before signing.
The third failure is staleness: a catalog built once and never maintained, so it drifts out of sync with what is actually being delivered and billed. The cure is to treat the catalog as a living document that the governance committee updates as services change and retire. A well maintained catalog is the buyer’s clearest evidence of what it is owed and what it can stop paying for, which is why building and maintaining it is core pre signing and transition work.
It is the line by line inventory of every transition service the seller provides after closing, with each service's scope, price, service level, dependencies, owners, and exit date recorded against it. It is the operational control document the buyer manages the whole transition from.
The schedules are the legal attachments to the master contract. The catalog is the operational view the buyer works from. In a well run deal they reconcile to each other, with the same services, prices, and dates appearing consistently across both.
Before signing. Building it early forces a full discovery of every service the carved out business depends on, while the buyer still has leverage to scope, price, and time box each one. A catalog assembled after close from invoices has already lost that leverage.
It is untracked, which usually means it surfaces after close as an undocumented dependency the seller charges for at a price the buyer never agreed. A thorough pre signing discovery that maps every consumed service is the protection against this.
How the catalog reconciles to the legal schedules behind the contract.
Read the article →The mechanics that retire each catalog entry on schedule.
Read the article →The costs that linger when services retire but expense does not. The catalog is the evidence base.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
A representative $48M-revenue carve-out lists fourteen services in its TSA. When the catalog is vague — scope by reference, exclusions unstated, exit terms set only at the master-agreement level — the same estate drifts to $6.8M over twelve months. Pinned to the per-service template below, it runs to $5.1M in nine.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →