Executive summary
A buy-and-build strategy acquires a platform company and then adds smaller businesses to it. The investment case usually rests on two sources of value: the added EBITDA of each acquired business, and the possibility that a larger combined company is valued at a higher multiple than the pieces were bought for. A third source, cost and revenue synergies, is real but is the smallest and slowest of the three in most cases.
Each of these depends on one thing that rarely appears in the model: the platform's ability to absorb the next add-on without breaking the last one. A platform that has no repeatable integration method, a finance function that cannot close the books for a new entity within a month, and a leadership team already stretched across the first acquisition will turn each add-on into a distraction. The multiple expansion assumption then fails, because buyers at exit see inconsistent reporting and uneven performance across the units.
This guide proposes an integration model for the platform itself: a decision on what the center owns and what stays local, a sequence for each add-on, a cadence that limits how many integrations run at once, and a short list of numbers that show whether the platform is getting stronger or just bigger. It is a model to adapt, not a standard. Any acquisition involves legal, tax, employment, and financing agreements that govern what you may change and when, so involve counsel and your advisers before acting on any integration step that touches contracts, employees, or lender terms. This is not legal advice.
When to use this
Use this guide when:
- You own or are building a platform and have signed, or expect to sign, a second or third acquisition.
- A sponsor's plan assumes a number of add-ons per year, and you need to test whether the platform can absorb that pace.
- Add-ons are performing unevenly, and the cause may be the integration approach rather than the businesses.
- You are choosing which functions to centralize and want a way to make the call that is not driven by whoever argues loudest.
- You are preparing the platform for sale and want the combined business to look like one company to buyers.
For the single-deal sequence from signing to the first year, use the PMI playbook: Day 1 to Day 365. This guide sits above it: it decides how the platform handles every deal, while the PMI playbook handles each one.
Diagnostic questions
Answer these about the platform as it is today, not as the plan describes it.
- How many acquisitions has the platform completed, and how long did each take to reach the reporting and controls standard of the platform?
- Can the platform close its books and report monthly for the newest add-on on the same calendar as the rest of the group?
- Is there a named integration lead for each active deal, and is that person also doing a day job?
- What did the last integration cost in management time, one-time spend, and disrupted customers, compared with the plan?
- Which functions are centralized today (finance, procurement, IT, HR, pricing), and who decided?
- Are the acquired businesses reporting in the same chart of accounts, or is consolidation done by spreadsheet?
- What does each add-on's leadership team think the platform provides to them, and is it true?
- How much of the synergy case depends on a function that has not been centralized yet?
- Which customers or suppliers overlap between the platform and the add-ons, and who owns those relationships?
- If two integrations run at the same time, what breaks first?
- What does your lender's agreement require for reporting on acquired entities, and by when?
- What would a buyer at exit see if they looked at the three most recent add-ons side by side?
Question 10 is the planning constraint. Whatever the answer is, the pace of the acquisition plan should not exceed it.
The framework: three layers
The platform integration model separates what the center owns, what the business units keep, and what is decided deal by deal.
| Layer |
Principle |
Typical examples |
Decision owner |
| Center (always) |
One answer for the group; inconsistency creates risk or cost |
Financial reporting standards, chart of accounts, treasury and lender compliance, legal entity management, security baseline, group policies |
CFO and CEO |
| Shared (by capability) |
Centralize when the platform can do it better and the unit gains |
Payroll and benefits administration, indirect procurement, insurance, ERP hosting, back-office accounting |
Platform COO with the unit lead |
| Local (default) |
Close to the customer; differences are the source of the business's value |
Sales relationships, product and service delivery, local pricing within group guardrails, brand where it matters, front-line management |
Business unit lead |
A test for each function
For each function, ask four questions in order.
- Does inconsistency create risk? If yes (reporting, treasury, security), centralize.
- Does scale reduce cost or improve quality? If yes and the platform has the capability today, move it to shared; if the capability is not there yet, build it first.
- Is the function part of why customers buy? If yes, leave it local, and set guardrails instead.
- Is the unit's current approach better than the platform's? If yes, adopt it group-wide. A good add-on is a source of practices, not only EBITDA.
The order matters. Many integration plans centralize by default and then discover they have damaged the thing that was bought. A clear local list, agreed with the acquired leadership before signing, is a retention tool as much as an operating one. See people and organization due diligence for how to assess leaders before you promise anything.
Sequence for each add-on
| Stage |
Window |
Focus |
Gate to the next stage |
| Screen and select |
Before LOI |
Fit, integration complexity, and capacity; see the add-on acquisition screening scorecard |
Scorecard result and capacity check approved |
| Diligence |
Pre-signing |
Confirm the operating facts, working capital, and integration costs; see operational due diligence checklist |
Integration plan drafted with owners |
| Stabilize |
Day 1 to Day 30 |
Do not break anything: payroll, customers, suppliers, systems access |
Day 1 issues closed; local leaders in place |
| Connect |
Day 30 to Day 90 |
Reporting, treasury, and controls onto group standards |
First group close on the standard calendar |
| Capture |
Day 90 to Day 365 |
Shared services and synergies, in the order the center is ready for them |
Synergies tracked to realized EBITDA |
| Normal |
After year one |
The add-on runs as a unit of the platform |
Included in standard operating reviews |
The "connect" step precedes "capture" deliberately. Synergies cannot be tracked in a business that cannot report on the group's terms. The synergy tracking model describes how to follow each synergy from the model to realized EBITDA.
Step-by-step: building the platform model
- Write the capability inventory. List each function and rate the platform's current capability as ready, partial, or not ready. Owner: COO. Output: one-page inventory.
- Assign each function a layer using the four-question test. Owner: CEO and CFO. Output: layer map with named owners.
- Set the integration capacity. Decide the maximum number of concurrent integrations the platform can run, based on named leads and the finance close. Owner: CEO. Output: a number the acquisition plan must respect.
- Standardize the reporting package. Define the monthly package every unit delivers, with the same definitions and calendar. Owner: CFO. Output: reporting standard, plus a template.
- Define the Day 1 to Day 90 runbook for every add-on, covering payroll, banking, insurance, systems access, customer communication, and first close. Owner: integration lead. Output: reusable runbook. See the PMI playbook.
- Build the synergy register with a range for each synergy and an owner for each. Owner: FP&A. Output: register. Use the acquisition synergy calculator to size cases.
- Create an integration cost budget for each add-on, including management time. Owner: CFO. Output: one-time cost estimate that the screening step uses.
- Run a monthly platform review with all units on the same agenda. Owner: CEO. Output: decisions and an issues log.
- After each add-on, hold a lessons review at day 100 and update the runbook. Owner: integration lead. Output: revised runbook.
- Prepare for exit by keeping each unit's history in the same structure, so a buyer sees one company. Owner: CFO. Output: consolidated historicals with consistent policies.
Worked example (illustrative)
The figures below are made up to show how the economics fit together. They are not benchmarks, and multiples are assumptions, not predictions.
A platform has EBITDA of $10.0M. Over two years it buys three add-ons.
| Add-on |
EBITDA ($M) |
Assumed purchase multiple |
Price ($M) |
Run-rate synergy ($M) |
One-time integration cost ($M) |
| A |
1.2 |
5.0x |
6.00 |
0.15 |
0.18 |
| B |
0.9 |
4.5x |
4.05 |
0.10 |
0.12 |
| C |
1.5 |
5.5x |
8.25 |
0.20 |
0.25 |
| Total |
3.6 |
|
18.30 |
0.45 |
0.55 |
Checks: 1.2 + 0.9 + 1.5 = 3.6. 1.2 × 5.0 = 6.00; 0.9 × 4.5 = 4.05; 1.5 × 5.5 = 8.25; the sum is 18.30. Synergies: 0.15 + 0.10 + 0.20 = 0.45. Integration costs: 0.18 + 0.12 + 0.25 = 0.55.
Combined EBITDA with synergies = 10.0 + 3.6 + 0.45 = $14.05M.
Suppose the group is valued at an assumed 8.0x at exit. Value = 14.05 × 8.0 = $112.4M. The platform alone at the same multiple would be 10.0 × 8.0 = $80.0M. The incremental value is $32.4M. Subtract the $18.30M paid and the $0.55M integration cost, and the value created is $13.55M.
Check: 32.4 − 18.30 − 0.55 = 13.55.
How the $13.55M breaks down:
| Source |
$M |
Calculation |
| Add-on EBITDA bought below the group multiple |
10.50 |
3.6 × 8.0 − 18.30 |
| Synergies at the group multiple |
3.60 |
0.45 × 8.0 |
| Integration cost |
(0.55) |
One-time |
| Value created |
13.55 |
10.50 + 3.60 − 0.55 |
What this tells the operator:
- Most of the value (10.50 of 13.55) comes from buying at lower multiples and holding the group multiple. If the exit multiple is 7.0x instead of 8.0x, the same group is worth 14.05 × 7.0 = 98.35, the incremental value is 98.35 − 70.0 = 28.35, and the value created falls to 28.35 − 18.30 − 0.55 = 9.50. The multiple assumption deserves more scrutiny than the synergy estimate.
- The multiple holds only if the combined company looks like a coherent, well-run business, which is what the integration model is for.
- Synergies are the smallest piece. Overestimating them is a common error, and doubling them would add 3.60, still less than the multiple effect.
- The integration cost looks small, but it excludes management time and any customer disruption, both of which the budget should include.
Templates
Function layer map (copy into a spreadsheet)
| Function |
Platform capability (ready / partial / not ready) |
Layer (center / shared / local) |
Owner |
Standard to meet |
Date |
Add-on integration scorecard
| Add-on |
Day 30 gate met? |
First group close date |
Controls gaps open |
Synergies identified ($) |
Synergies realized ($) |
Leader retained? |
Open issues |
Monthly platform review agenda
- Group results and each unit's results on the same package (15 min).
- Integration status for each active add-on against its gates (15 min).
- Synergy register: realized versus planned, and owners (10 min).
- Capacity check: can the next add-on proceed? (10 min).
- Decisions needed and owners (10 min).
Metrics and KPIs
| Metric |
Formula |
Data source |
| Days to first group close |
Date of first close on the group calendar − closing date |
Finance close log |
| Add-ons on the group reporting standard |
Units reporting on the standard ÷ total units |
Reporting tracker |
| Realized synergy ÷ planned synergy |
Realized run-rate ÷ plan, by add-on |
Synergy register |
| One-time cost versus budget |
Actual − budget, including estimated management time |
Integration budget |
| Leader retention |
Key leaders still in role after 12 months ÷ key leaders at closing |
HR records |
| Customer retention in acquired units |
Retained customers ÷ customers at closing |
CRM and billing |
| Concurrent integrations |
Count of active integrations |
Platform review |
| Organic growth by unit |
Revenue change excluding acquisitions |
Monthly package |
Targets by method. Use the platform's own previous add-on as the baseline and set the next one's targets against it, for example fewer days to first group close than the last deal. Use contractual dates (lender reporting deadlines, earn-out periods) as fixed floors. Compare synergy realization to the original range, not to a number from another company. Avoid a generic benchmark for any of these.
Common mistakes
- Centralizing everything on Day 1. The first 30 days are for stability. Customers and key people leave when basics break.
- Buying faster than the platform can integrate. The capacity number from the diagnostic must cap the pace, not the sponsor's target.
- Modeling the exit multiple as a given. Test the plan at a lower multiple. See the example above.
- Counting synergies before the function exists. A procurement synergy needs a procurement function that can deliver it.
- No standard reporting. If each unit reports differently, the group cannot manage it or sell it.
- Ignoring management time. Integration consumes the same people who run the businesses. Put it in the cost budget.
- Treating the add-on as only EBITDA. Some add-ons carry better practices than the platform. Capture them.
- Skipping contracts and lender terms. Change of control clauses, customer consent rights, employment terms, and covenants affect what you can do and when. Review them with counsel before acting.
AI prompt assistance
AI can help organize the inventory and draft runbooks. It cannot judge your leaders or interpret your contracts. Supply your own data and verify each output.
1. Draft the capability inventory.
I will paste a list of our group functions and a short description of how each works today. Create a table with columns: function, current capability (ready, partial, not ready), the evidence for that rating from my description, and the risk of centralizing it now. Use only what I wrote. Mark anything unclear as "unknown".
Check: review each rating with the function owner.
2. Stress-test the value creation math.
Here are three add-ons with EBITDA, purchase multiple, synergy, and integration cost, plus the platform EBITDA and an assumed exit multiple. Compute combined EBITDA, group value, incremental value, and value created at exit multiples of 6x, 7x, and 8x. Show each step in a table.
Check: recompute one scenario by hand and compare to the table.
3. Draft a Day 1 to Day 90 runbook outline.
Draft an outline for an add-on integration runbook with sections for payroll, banking, insurance, systems access, customer communication, and first group close. For each section list the tasks, an owner role, and the evidence that it is complete. Do not include legal conclusions.
Check: have the integration lead and counsel edit the outline before use.
Implementation guide
| Phase |
Timing |
Owner |
Exit criteria |
| Inventory and layers |
Days 1-30 |
COO, CFO |
Capability inventory and layer map approved |
| Standards |
Days 30-60 |
CFO |
Reporting package and close calendar fixed; capacity number set |
| Runbook |
Days 45-75 |
Integration lead |
Day 1 to Day 90 runbook written and reviewed |
| Governance |
Days 60-90 |
CEO |
Monthly platform review running; synergy register live |
| Iterate |
After each add-on |
Integration lead |
Day-100 lessons review completed; runbook updated |
Governance: the CEO owns the pace, the CFO owns the reporting standard, the COO owns shared services, unit leads own local decisions, and the integration lead owns the runbook. Review progress at the board level every quarter.
Downloadable assets
The function layer map, add-on integration scorecard, and monthly review agenda are designed to be copied into a spreadsheet. To size synergy cases for the register, use the acquisition synergy calculator.
Related resources
Frequently asked questions
What is a buy-and-build strategy?
A buy-and-build strategy acquires a platform company and then adds smaller businesses to it, aiming to grow EBITDA and to build a larger company that may command a higher valuation at exit. It works only if the platform can integrate each add-on without disrupting customers, reporting, or the previous acquisition.
What should be centralized after an add-on acquisition?
Centralize what creates risk when inconsistent, such as financial reporting, treasury, legal entities, and security, then centralize shared services only where the platform is ready. Leave customer-facing functions local by default and set guardrails. Review contracts, employment terms, and lender requirements with counsel before changing anything that touches them.
How many add-ons can a platform integrate at once?
There is no universal number. The limit is the number of integrations the platform can staff with named leaders while closing the books on the group calendar. Answer the diagnostic questions about your last integration, set a cap from that evidence, and make the acquisition plan respect it.
Where does the value come from in a buy-and-build?
Value usually comes from the added EBITDA, from buying smaller businesses at lower multiples than the combined company may be valued at, and from synergies. The multiple effect is often the largest and the least certain, so test the plan at a lower exit multiple, as the worked example shows.
How do you track synergies in a buy-and-build?
Keep a register with each synergy, a range, a named owner, a start date, and realized run-rate by month, and connect it to the reporting package. Count a synergy as realized only when it shows in the unit's results. The synergy tracking guide describes the method in detail.
How this works in a System of Performance
A buy-and-build platform depends on knowing, for every unit, what was planned, what happened, and what was decided. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. To see how your own units compare on the same measures, bring it to us as a launch partner.