A tech company rarely starts an acquisition process because the spreadsheet looks interesting. It starts because leadership sees a product gap, a talent gap, a customer gap, or a timing gap in the market. The pressure usually lands on a small group of people. The CFO wants the economics to hold up. The CTO wants to know whether the platforms can merge. The hiring leader wants to know which engineers must stay for the deal to work.
That’s where merger and acquisition modeling stops being a finance exercise and becomes an operating tool. A good model doesn’t just ask whether the buyer can afford the target. It asks whether the combined company will work in a practical setting, considering its actual teams, operational systems, and the inevitable integration friction.
Table of Contents
- Why Every Tech Deal Needs a Robust M&A Model
- Laying the Foundation with Assumptions and Forecasts
- Structuring the Deal Sources Uses and Price Allocation
- Building the Pro-Forma Combined Financials
- The Bottom Line Accretion and Dilution Analysis
- Stress-Testing Your Model for Tech-Specific Risks
- Common Pitfalls Best Practices and Next Steps
Why Every Tech Deal Needs a Robust M&A Model
A software buyer signs a letter of intent expecting three clean wins. The acquired product should fill a roadmap gap, the engineering team should add delivery capacity, and overlapping costs should come out after close. Six months later, the buyer is still running two cloud environments, two support teams, and two product architectures. Key developers have left, customer migrations are behind schedule, and the original return case no longer holds.
That is why a detailed merger and acquisition modeling process matters in tech deals. It gives the deal team a way to test whether the purchase price still makes sense once timing, retention risk, integration cost, and execution drag are reflected in the numbers.
In any acquisition, the model needs to answer a familiar finance question: does the deal improve results for the buyer after financing, purchase accounting, and integration costs? In technology transactions, that answer depends on operating details that generic models often treat too lightly. Revenue synergies may depend on product compatibility. Cost synergies may require retiring duplicated tools and vendors without slowing releases. Margin assumptions may hinge on whether senior engineers, product leaders, and customer-facing technical staff stay through the integration period.
Those are not side notes.
If the investment case depends on IP transfer, engineering team continuity, platform consolidation, or customer migration, those assumptions should be visible in the model and tied to timing. A CTO reviewing the deal usually wants to know whether the plan assumes stable release velocity while systems are merged. A hiring leader usually wants to know whether the target’s top technical talent is likely to stay long enough to deliver the roadmap the buyer is paying for. Nexus IT Group’s audience sees this firsthand, which is why how recruiting shapes PE investment success belongs in the conversation earlier than many finance teams expect.
Cross-border deals add another layer. Buyers evaluating an Israeli target, for example, may need to account for local timing, approvals, and transaction mechanics before they can set realistic closing and integration assumptions. The legal process for M&A in Israel can directly affect deal timing, fees, and the period in which synergy capture is realistic.
A good model does more than organize numbers. It forces the team to price the actual work of combining products, people, and infrastructure, then decide whether the deal still earns its cost.
Laying the Foundation with Assumptions and Forecasts
A tech buyer can pay the right headline price and still miss the deal on the numbers because the forecast assumes engineers stay, product releases land on time, and customers accept a platform migration with little disruption. Those are not spreadsheet details. They are valuation drivers.
A useful M&A model starts with a simple discipline: forecast each business as it would perform on its own, then layer in only the changes that are likely after close. The model still needs the standard outputs, including combined earnings impact and accretion or dilution. But in tech deals, the quality of the answer depends on whether the assumptions reflect how software gets built, sold, supported, and integrated.
Separate deal assumptions from operating assumptions
Keep these two categories distinct from the start. If they get mixed together, the team can end up using hoped-for synergies to hide weak standalone performance.
Deal assumptions answer transaction questions:
- Purchase consideration: cash, stock, or a mix
- Financing structure: new debt, existing cash, or equity issuance
- Closing timing: the date the deal begins affecting reported results
- Transaction adjustments: debt repayment, cash acquired, fees, and other closing items
Operating assumptions answer business performance questions:
- Standalone growth: revenue trajectory for buyer and target before integration benefits
- Margins: gross margin, operating expenses, and cost structure by function
- Synergies: cost savings and revenue upside, with timing attached
- Integration friction: temporary costs, delayed initiatives, and lower productivity during the transition
That last point gets understated in many board decks. Integration friction is not a rounding item in a technology acquisition. If two engineering teams use different architectures, release cadences, or security processes, the model should show a slower path to savings and a higher near-term cost base.
Build forecasts around business drivers, not broad growth rates
Tech companies do not all scale the same way. A vertical SaaS company with low churn behaves differently from an IT staffing firm, a managed services business, or a product-led platform with heavy cloud spend. Using one generic growth line across all of them is how models drift away from reality.
Start with the operating drivers that management teams use to run the business.
| Model area | Better question to ask |
|---|---|
| Revenue | Is growth driven by seats, renewals, usage, project volume, placements, or price increases? |
| Gross profit | Which delivery costs move directly with revenue, and which stay fixed for a period? |
| Operating expense | Which functions can be consolidated, and which need added investment to protect the roadmap? |
| Capital needs | Will the integration require tooling changes, data migration, security work, or customer onboarding support? |
In tech M&A, forecast quality often improves when finance works backward from product and delivery realities. If the target sells annual subscriptions but relies on services teams to implement complex deployments, revenue may look recurring while margins behave more like a hybrid services model. If the buyer plans to consolidate platforms, cloud hosting, QA, and developer tooling may rise before they fall.
Compensation assumptions deserve the same scrutiny. If the thesis depends on keeping machine learning engineers, platform architects, or security leaders, market pay has to be reflected in the plan. Benchmarks such as AI engineer salary ranges in the US help test whether retention packages, backfill costs, and hiring timelines are grounded in the current hiring market.
Leadership teams should also judge the acquisition against other capital deployment options. Capstacker business investment insights is useful context for that comparison, especially when the buyer is weighing an acquisition against internal product investment or hiring.
Turn talent and IP risk into explicit model inputs
Tech deals separate from standard industrial templates in this context. The value often sits in people, code, product knowledge, and the team’s ability to keep shipping during integration.
Model those factors directly:
- Critical-role retention: principal engineers, engineering managers, product leaders, security specialists, and customer-facing technical staff
- Backfill cost and timing: salary, recruiting fees, signing packages, and ramp time if key people leave
- Integration staffing: temporary architecture oversight, program management, migration support, and security review
- Productivity loss: slower release cycles and delayed customer work while systems and reporting lines change
- IP transfer and reuse: whether the buyer can integrate the codebase quickly, or must invest to rewrite, document, or replatform parts of it
This does not require false precision. It requires visibility. A model can use scenarios instead of pretending the team knows the exact retention rate or integration timeline on day one.
The best assumption sets are specific enough to be challenged. If management says the target’s engineering team will deliver the same roadmap while moving to a new stack, consolidating tools, and taking on migration work, the model should force that claim into costs, timing, and execution risk. That is how an M&A model becomes decision support instead of a polished spreadsheet.
Structuring the Deal Sources Uses and Price Allocation
A tech buyer agrees to a price that looks sensible in the LOI. Two weeks later, the model shows a larger cash need, more debt paydown than expected, retention packages that were never in the first draft, and amortization that cuts into reported earnings right after close. That is the point where deal structure stops being legal paperwork and becomes economic reality.
The Sources & Uses schedule and the Purchase Price Allocation, or PPA, are the schedules that force that reality into view. They show how the deal gets funded, where the cash goes, and which accounting adjustments will shape the first years of combined results.
Start with sources and uses
This schedule is straightforward on purpose. Every dollar has to come from somewhere, and every dollar has to be assigned to a use.
Sources usually include buyer cash, new debt, and stock issued as consideration.
Uses usually include the equity purchase price, refinancing or repaying target debt, transaction fees, and any cash payments tied to the close.
That schedule does more than tidy up the model. It often changes the conversation in a tech deal. A buyer may be comfortable with the headline price, then realize the actual cash requirement is much higher once debt-like items, deferred revenue adjustments, change-of-control payouts, or retention packages for key engineers are included. Breaking Into Wall Street’s merger model walkthrough highlights Sources & Uses and PPA as core schedules because they capture the full economic cost of a transaction, including the write-ups that later flow into depreciation and amortization.
For software and IT services deals, I also want this schedule to separate true purchase consideration from post-close operating needs. If a buyer plans to spend heavily on engineering integration, cloud migration, security remediation, or talent retention, those costs may sit outside formal consideration, but they still affect returns.
Then allocate the purchase price
Once the funding is clear, the buyer has to determine what it bought.
Under Purchase Price Accounting, the target’s assets and liabilities are marked to fair value, identifiable intangible assets are recognized, and the remaining excess purchase price becomes goodwill. For an IT acquisition, a 30 to 40% premium can create $2 to $5M in additional annual D&A for every $10M of purchase price, according to Wall Street Prep’s merger model guidance. That can materially change pro forma margins, especially when the target’s standalone earnings were already thin.
In tech transactions, the main PPA judgment is rarely about fixed assets. It is about intangible value and how long that value lasts. Common categories include:
- Customer relationships, which may be valuable but often amortize over a finite life
- Proprietary software or code, especially when product capability is central to the deal thesis
- Developed technology, which matters in platform acquisitions and product tuck-ins
- Trade names or brand value, which may matter less in some B2B transactions but still need to be assessed
The hard part is not listing these assets. The hard part is assigning values that match operating reality. If the acquired codebase needs major refactoring before it can be integrated, or if product knowledge sits with a small group of engineers who may leave after close, the value assigned to technology should reflect that execution risk.
What often gets missed in tech deals
The accounting entries are technical. The business effect is easy to understand. Higher depreciation and amortization reduce reported earnings after close, even when the cash left the business on day one.
That creates a real boardroom tension. The CEO may see strategic fit. The CTO may see a faster product roadmap. Finance sees lower near-term EPS and a balance sheet loaded with goodwill and amortizing intangibles. A strong model has to show all three views at once.
Buyers overpay when accounting effects, retention costs, and integration work are pushed out of sight until late in the process.
That risk is higher in technology deals because a meaningful share of value often depends on assets that are hard to transfer cleanly. Code can be rewritten. Teams can leave. Product architectures can clash. Customer relationships can weaken if service levels slip during integration. A disciplined PPA process helps the deal team test whether the premium is being paid for assets the buyer can retain, integrate, and monetize.
Building the Pro-Forma Combined Financials
After the assumptions, funding, and accounting schedules are built, the model moves into its most operational stage. The two businesses have to be combined into one set of financial statements that answers a simple question: what does the company look like as if the deal has already happened?
That’s the role of the pro forma model. It’s not a rough sum of two P&Ls. It’s a structured rebuild of the income statement, balance sheet, and cash flow statement after transaction effects, purchase accounting adjustments, and synergy assumptions are layered in.
How the combined income statement gets built
The income statement usually gets modeled first because it carries the most visible operating effects.
Start with the acquirer’s forecast. Add the target’s forecast. Then adjust for the items created by the transaction and the post-close operating plan.
That often includes:
- Revenue adjustments for expected cross-sell opportunities, customer overlap, or any revenue loss tied to churn risk.
- Cost synergies from removing duplicated G&A, consolidating vendors, or rationalizing infrastructure.
- Incremental D&A created by fair value write-ups and identified intangibles.
- Financing effects such as interest expense tied to acquisition debt.
The logic should be transparent. If cost savings depend on retiring duplicate systems, those savings shouldn’t appear before the migration work is done. If revenue upside depends on a combined sales motion, it shouldn’t appear on day one.
Balance sheet changes that matter
The balance sheet is where many non-finance stakeholders lose the thread, but it contains several of the most important deal mechanics.
A proper pro forma balance sheet typically reflects:
- Target assets and liabilities added in: but not at legacy carrying values when PPA applies.
- Target equity removed: because the acquired company’s old equity doesn’t survive the transaction.
- Goodwill and intangibles created: based on the purchase price allocation.
- New financing reflected: including debt raised or cash spent by the buyer.
- Working capital combined: subject to any close-date adjustments.
This is also where model discipline matters. If goodwill, debt, and cash aren’t flowing correctly, the cash flow statement will usually expose the problem.
A pro forma model becomes credible when the balance sheet reconciles cleanly and the cash flow statement follows naturally from the operating and deal assumptions.
Why the cash flow statement keeps the model honest
The cash flow statement is often the least discussed page in early deal meetings and one of the most useful. It tests whether the combined business generates enough cash to support the strategy presented in the income statement.
For tech deals, that matters because reported earnings and operating reality can diverge. A company may look profitable while still absorbing heavy integration effort, migration costs, or working capital pressure.
Three checks help here:
| Check | What it tells the team |
|---|---|
| Earnings to cash conversion | Whether reported profit is turning into usable cash |
| Financing burden | Whether acquisition debt creates pressure after close |
| Investment needs | Whether product, platform, or infrastructure spending remains elevated |
When these three statements tie together properly, the model stops being a collection of tabs and starts functioning as a decision tool. That’s when the board, the CFO, and the operating team can debate the same future using the same financial picture.
The Bottom Line Accretion and Dilution Analysis
At some point, every acquisition debate narrows to a direct question. Does this deal improve the buyer’s earnings per share, or reduce it?
That’s the purpose of accretion and dilution analysis. After the pro forma financials are built, the team calculates pro forma net income and compares pro forma EPS against the acquirer’s standalone EPS. If the result is higher, the deal is accretive. If it’s lower, the deal is dilutive.
What the board is really looking for
The arithmetic is straightforward. The interpretation is not.
A board doesn’t look at accretion and dilution in isolation. It looks at what had to be assumed to produce the answer. If a deal appears accretive only because synergies arrive unusually fast or retention risk is ignored, the model hasn’t reduced risk. It has disguised it.
The key components are usually:
- Pro forma net income: after financing cost, purchase accounting effects, and synergies.
- Pro forma share count: especially important when stock is used as consideration.
- Standalone buyer EPS: the baseline for comparison.
For teams involved in private equity-backed growth or platform roll-ups, the same discipline applies beyond public-market optics. Strategic operators still need to know whether the transaction improves the earnings power of the business after realistic integration assumptions. This broader operating lens aligns well with the ideas in the operating partner playbook for private equity success.
How to interpret the result without oversimplifying it
An accretive result is helpful, but it isn’t automatic proof of a good deal. A dilutive result isn’t automatic proof of a bad one either.
A practical reading looks like this:
Accretive often means the transaction structure, target earnings, and modeled synergies support near-term per-share earnings.
Dilutive often means one or more of the following is true: the premium is high, financing is expensive, stock issuance is meaningful, or accounting charges weigh on earnings early after close.
Neutral can still be useful if the strategic logic is strong and the integration path is credible.
The important point is that accretion and dilution analysis should compress a large amount of operating and financing information into one decision output. It should not replace judgment. It should sharpen it.
Stress-Testing Your Model for Tech-Specific Risks
A merger model that works only under one clean set of assumptions isn’t much of a deal tool. It’s a presentation.
Technology deals need pressure-testing because a large portion of value sits in assets that don’t behave like factory equipment or commodity inventory. Engineering talent can leave. Product integration can stall. Platform migration can take longer than expected. Revenue synergies can slip while teams are busy just keeping systems stable.
A particularly important reminder comes from software and cloud deal research. A 2022 study suggests that 60 to 70% of realized value in tech mergers is tied to post-integration execution and talent retention, yet standard modeling guides rarely code variables such as engineering attrition or integration headcount into the model, as noted in Street of Walls’ discussion referencing that research.
Generic sensitivity analysis is not enough
A standard sensitivity table might test purchase price against synergy realization. That’s useful, but it’s incomplete for a tech acquisition.
If the value thesis depends on product continuity or team retention, then the model should test those variables directly. Otherwise, the sensitivity analysis is centered on finance inputs while the actual risk sits in operations.
The most dangerous model in a tech deal is the one that stress-tests valuation inputs but leaves engineering and integration assumptions untouched.
The variables worth pressure-testing
The strongest stress tests usually sit close to how the business operates.
- Engineering retention: If key developers or architects leave, product roadmaps can slow and customer confidence can weaken.
- Integration headcount: Combining platforms often requires temporary labor that isn’t visible in a generic synergy slide.
- Migration timing: Delayed platform or data integration can postpone both cost savings and cross-sell revenue.
- Customer continuity: In services or staffing businesses, account-level disruption can reduce near-term billings.
- Infrastructure consolidation: Savings from retiring duplicated tools or cloud spend usually arrive later than the first draft assumes.
A simple way to structure this is to assign a base case, downside case, and upside case to each operational driver. Excel can handle that with scenario toggles, assumption switches, and sensitivity tables without turning the workbook into a black box.
Build scenarios around operating reality
For a CTO or engineering leader, the most useful scenarios usually look operational first and financial second.
| Scenario | Operating description | Likely model effect |
|---|---|---|
| Base case | Integration proceeds on planned timeline with core team retained | Synergies arrive on schedule |
| Downside case | Technical leads leave and platform migration slows | Revenue upside slips and costs stay elevated |
| Upside case | Teams align quickly and duplicated tools are retired earlier | Cost savings appear sooner and margins improve |
This kind of scenario design changes the conversation in diligence meetings. Instead of debating whether a synergy percentage feels reasonable, the team debates whether specific operating events are likely. That's a much healthier discussion.
The result is a model that behaves more like a management tool. It doesn't predict the future perfectly. It shows which assumptions deserve the most scrutiny before the deal closes.
Common Pitfalls Best Practices and Next Steps
Most merger models don't fail because Excel breaks. They fail because the team asks the model to confirm a deal instead of testing one.
That usually shows up in familiar ways. Synergies are aggressive. Integration costs are thin. Retention assumptions are optimistic. Timing is compressed. The workbook may still calculate perfectly, but the answer is biased from the start.
Recent research also points to a problem earlier in the process. Research on acquisition prediction and technology portfolio similarity shows that predictive analytics and technology similarity can improve acquisition prediction accuracy, yet many M&A models are built only after a target is already chosen. That creates a blind spot. Teams may build detailed financial logic around a target that was selected with weak evidence of technical fit.
Mistakes that weaken the model
Several errors show up repeatedly in technology transactions.
- The synergy trap: cost savings are entered cleanly, but no one ties them to actual integration milestones.
- Soft treatment of talent risk: the deal depends on key people staying, yet no scenario meaningfully tests departures.
- Under-modeled integration work: leadership assumes systems will merge because they should, not because the organization has capacity to do it.
- Overconfidence in target selection: buyers jump into detailed modeling before checking whether the target's technology stack and operating model fit.
- Static use of the model: the workbook gets used for approval and then ignored during integration.
Modeling habits that actually help
The best models are usually easier to audit, not more impressive to look at.
- Separate inputs, calculations, and outputs. A reviewer should know where assumptions live and where formulas shouldn't be overwritten.
- Use clear labeling. Tabs should read like a process, not like personal shorthand.
- Avoid hardcoding inside formulas. Assumptions belong in dedicated cells.
- Build error checks. Balance sheet balance, sign checks, and circularity flags save hours later.
- Document judgment calls. If a synergy assumes a platform migration, note the operational dependency next to the assumption.
- Refresh the model after diligence. Early-stage assumptions shouldn't survive unchanged after deeper technical and HR review.
A reliable model doesn't just produce an answer. It shows which assumptions drive that answer and where the deal can break.
What should happen after the model is finished
The model should hand off into execution. If it doesn't, the analysis never reaches the people responsible for making the deal work.
That handoff usually includes:
- Retention planning: identifying which engineers, product leaders, recruiters, and client-facing specialists matter most to value preservation.
- Org design choices: deciding where overlap is efficient and where forced consolidation would create operating risk.
- Integration sequencing: matching synergies to real milestones instead of board-level slogans.
- Hiring strategy: deciding whether the combined company needs backfills, new leadership, or temporary integration support.
For technology employers, that final step is often the difference between a financially approved deal and a successful one. Merger and acquisition modeling works best when finance, product, engineering, and talent leaders all use it as a shared decision framework.
When a transaction depends on retaining specialized engineers, integrating platforms, or hiring around post-close gaps, nexus IT group can support the part of the deal model that spreadsheets alone can't solve. The firm helps technology employers secure hard-to-find talent across AI, cloud, cybersecurity, software, data, and IT leadership roles so integration plans have the people required to work in practice.