Private equity and portfolios
Portfolio data screen: scoring criteria to rank companies for licensing fit
By SourceX Editorial · Updated
Short answer
A portfolio data screen ranks operating companies for licensing fit on eight criteria: rights clarity, approval path, record linkage, uniqueness, buyer fit, accessible history, export practicality and privacy burden. Treat rights and approvals as pass-or-park gates, weight linkage, uniqueness and buyer fit most heavily, and score everything from metadata, with no files shared.
Key takeaways
- Rights clarity and a clear approval path are gates, not scores; a company that fails either is parked, not rejected.
- Record linkage, uniqueness and buyer fit carry the most weight because they drive what a licensee values.
- Score record families inside each company, because one company can hold both a strong and a weak archive.
- Use four levels, strong, partial, weak and unknown, and never average an unknown into a pass.
- Every input can come from metadata a company leader provides without exporting a single file.
What a portfolio data screen should score#
A portfolio data screen should score the factors that decide whether a licensee would want a company's records and whether the company can license them. Revenue, margin and growth are not on the list; they matter to the fund but say little about whether a long run of dispatch records or code reviews is licensable.
The rubric below groups eight criteria into two gates, three heavy-weight scores, two standard scores and one deduction. Keep the definitions fixed across companies so a head of portfolio operations can compare a vertical software business and an industrial distributor on the same page, and so the ranking can be defended when a portfolio CEO asks why their company is not first.
The eight criteria, weights and metadata inputs#
Each criterion has a weight, a metadata input a company leader can supply without opening a system or after a short call with IT, and a description of what a strong answer looks like. Nothing in the input column requires an export, a sample or a file.
| Criterion | Weight | Metadata input (no files) | Strong looks like |
|---|---|---|---|
| Rights clarity | Gate | Customer contract types, privacy notice history, known restrictions | Company-owned internal records under contracts that leave room for de-identified use |
| Approval path | Gate | Supplier entity, authorized signer, known lender and board consents | Named signer with consents identified and reachable |
| Record linkage | Heavy | Whether records connect a request, a decision and an outcome | Ticket to fix to release, or estimate to job to callback |
| Uniqueness and domain expertise | Heavy | How records are created and by whom | Expert judgment captured inside the workflow and hard to rebuild |
| Buyer fit | Heavy | Record families present and the language they are written in | Record types AI developers are seeking, predominantly in English |
| Accessible history | Standard | Years still exportable per system and any migration gaps | Several continuous years in the current system |
| Export practicality | Standard | System names, export routes and vendor term limits | Native export or API with no vendor restriction found |
| Privacy burden | Deduction | How much of the content centers on personal or sensitive data | Mostly business workflow content, with personal details incidental |
Why gates come before scores#
Gates come before scores because no amount of record quality makes up for a company that cannot grant a license. A distributor with excellent order exception history but customer contracts that bar any reuse of customer data cannot proceed until counsel finds room in those contracts, however well it would score on everything else.
Approval path works the same way. If nobody can say which legal entity holds the records after a string of add-ons, or a lender consent is needed during a strained refinancing, the company is parked with a note on what would change the answer.
Parking is not rejection. A contract template refresh, a completed refinancing or a system retirement can reopen the question, so keep parked companies on the list with their reason and trigger.
Scoring levels and rules#
Four scoring levels are enough, provided the evidence behind each score is written down. A score without a note cannot be challenged or updated when facts change.
- Never average an unknown into a pass; resolve it in the fuller inventory.
- Score record families separately when they differ sharply inside one company.
- Record who supplied each answer and when.
- Re-score after any migration, acquisition or change to the customer contract template.
| Level | Meaning | Example evidence |
|---|---|---|
| Strong | Clearly meets the criterion today | COO confirms tickets link to Jira issues from the start of the current helpdesk |
| Partial | Meets it for some record families or years | Linkage exists only after a CRM migration |
| Weak | Does not meet it without major work | Job notes are free text with no outcome field |
| Unknown | Not yet answered | IT has not confirmed export routes |
Score record families, not just companies#
Scoring record families rather than whole companies stops a strong archive from being hidden by a weak one. A vertical software company can hold excellent support and engineering history alongside a CRM full of thin, auto-logged activity, and averaging them produces a middling score that describes neither.
The output of the screen is therefore a ranked list of company and record-family pairs, such as a software company's ticket and issue history or a mechanical contractor's service agreements and maintenance visits. Those pairs map directly onto the packages a licensee would scope, which makes the next conversation concrete.
A related mistake is scoring what a CEO hopes is true rather than what IT has confirmed. Leaders often remember a system as holding more history than it does, especially after a migration. Where an answer matters to the ranking and comes only from memory, mark it partial until someone checks the system.
Turning scores into a ranked shortlist#
The ranking follows a fixed order so that gates, weights and deductions are applied the same way for every company. Resist adjusting the order for a company whose CEO is enthusiastic; enthusiasm matters for choosing among pilots, not for ranking.
- Step 1: apply the two gates and park any company or record family that fails.
- Step 2: rank the remainder on the three heavy criteria.
- Step 3: break ties with accessible history and export practicality.
- Step 4: apply the privacy burden deduction and note the preparation work it implies.
- Step 5: choose one or two pilots that score strong on heavy criteria and have simple approvals.
- Step 6: after the pilots, compare what was found with what the screen predicted and adjust definitions.
Illustrative: scoring a software holdco's first screen#
Illustrative: a fictional holding company owns four vertical software businesses serving marinas, commercial laundries, auto glass shops and event venues. Each business leader answers the metadata questions in a short call, and the head of portfolio operations scores them on one sheet.
The marina and auto glass businesses score strong on linkage, with tickets tied to issues and releases. The laundry business scores partial on history because a helpdesk migration lost older tickets. The event venue business passes both gates but scores weak on uniqueness, since most of its records are standard booking transactions. The group pilots the auto glass business first because its signer and lender consents are simplest, with the marina business next.
How the rubric relates to SourceX's framework#
The rubric borrows its weighting logic from the SourceX Enterprise Data Value Framework, a SourceX-developed methodology with qualitative ratings. The heavy criteria track the framework's uniqueness, domain expertise, human-generated signal and AI utility drivers; accessible history tracks recency and scale; the gates reflect its rights driver; and the deduction reflects privacy burden and preparation cost, which the framework treats as reducing net value.
SourceX's fit check uses the same metadata-only approach, so a company that has completed this screen can reuse its answers, and the fit check asks for no files, exports or samples. Companies that proceed then move through the SourceX five-step transaction one supplier at a time.
Frequently asked questions
Should revenue or headcount affect the ranking?
Only as a threshold. The typical fit for SourceX is 50+ full-time employees at peak, contractors excluded, with several years of operating history, and smaller specialized companies may be reviewed for a specific buyer request. Past that bar, record linkage, rights and approvals matter much more for licensing fit than company size or revenue.
How often should the screen be rerun?
Rerun it when something changes the inputs: an acquisition, a system migration or retirement, a new customer contract template or a refinancing. A scheduled refresh during annual planning keeps the shortlist current between those events.
Who should supply the metadata for each company?
The COO or CEO, with a short check from IT on systems and exports and from finance or counsel on contracts and lender terms. Ask only for answers they can give without exporting anything; unknowns are acceptable at this stage.
Can a parked company become a pilot later?
Yes. Gates often fail for fixable reasons such as an old contract template, a missing signer or a lender relationship in the middle of a refinancing. Record the reason for parking and the event that would reopen it, then revisit when that event happens.
Does buyer fit change over time?
It does. The record types AI developers seek shift as their products change. Treat buyer fit as the criterion most likely to move, and refresh it from current fit check feedback rather than an old list.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.