Technology Transfer Software: Tying a Royalty Cheque Back to the Clause That Earned It

Why a technology transfer office runs on joins nobody has made

A technology transfer office holds four kinds of record and almost never holds them together. Invention disclosures arrive from faculty on a form with an inventor list. Patent matters live with outside counsel and turn up as invoices with matter numbers that do not obviously map to anything. Licence agreements are signed PDFs in a folder containing the actual obligations of both parties. And money arrives as royalty reports in whatever format the licensee chose, then leaves as distributions under a policy written by a committee in 1997.

The join that nobody has made is the one that matters: this payment, from this licensee, against this clause, on this patent family, owned in these proportions, distributed to these inventors, one of whom left for industry six years ago and one of whom has died and whose share now goes to an estate. Ask a licensing director to trace one royalty cheque all the way through that chain and they will tell you honestly that it takes half a day and involves opening a signed PDF.

The consequences are quiet rather than dramatic, which is why offices tolerate them for years. Underpayment by licensees goes unnoticed because nobody compares the report to the contract terms. Annual minimums are missed and never invoiced. Diligence milestones lapse without anyone triggering the reversion clause the university negotiated for exactly that situation. Patent costs accumulate on families that will never license because nobody surfaced the annual spend against the revenue. Each of those is money the institution was entitled to and did not collect.

Problem 1: licence obligations sit in PDFs and never become diary entries

A licence agreement is a set of promises with dates attached. An upfront fee. An annual minimum payable each anniversary. Milestone payments on first commercial sale, on regulatory submission, on a funding round. A running royalty on net sales, usually tiered, with a definition of net sales that has been negotiated and is not the same as the last agreement's. Sublicence income share, often stacked differently from the direct royalty. Diligence obligations with dates. Reporting obligations with frequency. Termination and reversion triggers.

Inteum and Wellspring Sophia both do genuine agreement management and both will hold key terms in fields. Anaqua is a serious IP management platform, though its centre of gravity is corporate portfolios and law firm workflow rather than a university's distribution and funding compliance obligations. Across all of them the recurring gap is the same: the obligations that get keyed in are the ones somebody had time to key in, so the upfront fee and the royalty rate are captured and the diligence milestone in clause 6.3 is not. The clause that would have let you claw the technology back is the clause nobody entered.

A custom build treats the executed agreement as the source and extraction as a first class step. Document extraction over signed PDFs pulls the payment terms, the definitions, the milestones, the reporting frequency and the termination triggers into a structured obligation set, with the clause reference and a link to the page so a licensing officer verifies rather than transcribes. Every obligation becomes a dated diary entry that raises itself. This is the highest value use of a language model in the whole category, and it works because you are extracting from a document you already have rather than predicting anything.

Problem 2: royalty statements arrive in the licensee's format and nobody reconciles them

Quarterly, a licensee sends a report. One sends a PDF with a total. One sends a spreadsheet with product level detail and a currency conversion applied at a rate they chose. One sends an email with a number in the body. A large licensee sends a portal notification. Somebody in the office opens it, checks the arithmetic if they have time, and records the payment.

What almost nobody does is check the report against the agreement. Is the royalty base the net sales definition in this contract or a different one. Was the tier applied at the right threshold. Was the annual minimum credited or double counted. Is this quarter's figure plausible given last quarter and the product's market. Was a sublicence income share reported at all, given that you only found out about the sublicence from a press release.

A build makes reconciliation automatic and exception driven. Each statement, whatever its format, is parsed into line items and evaluated against the obligations extracted from that specific agreement. The system flags variance against contract terms, against prior periods and against the minimum, and it produces the query letter. Offices that install this typically find something in the first year, and it is usually not fraud, it is a licensee's finance team applying a definition from a different contract. That is a conversation you can only have if you noticed.

Problem 3: equity, sublicences and joint ownership break the data model

Packaged tools generally model a licence as one licensor and one licensee with a royalty. Real portfolios are not that shape. The university takes equity in a spinout instead of an upfront fee, and that equity dilutes across financing rounds and may carry anti dilution to a threshold. The spinout sublicenses to a larger company and the sublicence income share stacks on the direct royalty at a different rate. The patent is jointly owned with another institution under an agreement designating a lead and splitting costs and income in proportions that differ from ownership.

Each of those is a normal week in a large office and each of them is the reason someone maintains a spreadsheet beside the system. Equity in particular usually lives with the university's investment or foundation office in a completely separate record, so the licensing director cannot see the full position on a company they created.

A custom build models ownership and entitlement as their own graph rather than as fields on a licence. A patent family has owners with shares. An agreement has parties with entitlements. A spinout has a holding with a share class and a dilution history. Income arriving at any node distributes through the graph according to the rules attached to the edges. That sounds abstract until the first time a licensing officer answers, in one query, what the institution's total position in a company is across equity, royalties and sublicence income. That answer currently takes a week and three emails.

Problem 4: distribution and federal funding compliance are the parts you cannot get wrong

Net income distribution runs through your institution's policy: recover patent costs first, then split among inventors, department and central university in stated proportions. In practice it is complicated by inventors who have left, inventors who dispute their share, estates, tax treatment differing between employees and non employees, and finance systems that want the payment as a payroll instruction for one recipient and an accounts payable instruction for another.

Federally funded inventions carry their own obligations under Bayh Dole, reported through iEdison: disclosure to the funding agency, election of title, filing, and continued reporting on utilisation, each tied to a deadline. Miss one and the government can take title to the invention. That is not a fine, that is losing the asset. The government also holds a confirmatory licence and march in rights, and there is a US manufacturing preference attached to exclusive licences to sell in the United States. Any office that is not tracking those deadlines systematically is relying on an individual remembering.

A build enforces both. The distribution waterfall runs as a computation with a full audit trail per recipient, exports in the shape your finance system wants, and shows each inventor a statement they can see for themselves, which removes an extraordinary amount of email. Funding obligations become dated tasks generated automatically from the funding source on the disclosure, escalating before the deadline rather than after.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering disclosure intake, patent matter and outside counsel cost tracking, licence obligation extraction and royalty statement reconciliation runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding equity and cap table holdings, inter institutional agreement splits, the distribution waterfall with finance system export, inventor self service statements and federal funding compliance tracking runs $180,000 to $450,000 phased over 6 to 12 months.

What drives price up specifically in this sector: the finance system integration, because Workday, Banner and PeopleSoft each treat inventor payments differently and payroll versus accounts payable routing is genuinely fiddly. Docketing, if you want deadlines synchronised with outside counsel rather than tracked in parallel. Migration, because thirty years of matters and inventor records rarely leave a legacy system cleanly and historical distribution figures are usually the part that will not tie out. And the number of distinct royalty statement formats you receive, since each is a parsing profile.

Build versus buy, and when Inteum or Wellspring is the right answer

Buy if you are a smaller office with under about 30 active licences, no equity portfolio, and a straightforward distribution policy. Inteum covers disclosure through licence competently and is used across a great many offices for good reason. Wellspring Sophia is strong on the pipeline and portfolio side. If your complexity is normal, custom software is an expensive way to arrive at the same place with more risk.

Build when two or more of these are true. You hold equity in spinouts and cannot see the institution's total position in a company in one place. You have sublicence stacking or inter institutional agreements that your current system cannot represent, so somebody maintains a spreadsheet. You have never systematically reconciled a royalty statement against a contract. Your distribution waterfall requires manual calculation each cycle and inventors email to ask where their money is. Or your federal funding deadlines are tracked by a person rather than by a system.

Our position, stated plainly: the argument for building here is financial, not administrative. An office managing serious licence revenue that has never checked a statement against the contract is very likely leaving money on the table, and the obligations and reconciliation layer usually pays for itself faster than anything else we build in higher education. If your revenue is small, do not build, because the same maths runs the other way.

How to choose a developer for technology transfer software

Ask them to model joint ownership and sublicence stacking on a whiteboard before you sign. A developer who has done this will draw ownership shares, agreement parties, entitlements and a distribution graph, and will ask what happens when a sublicence income share and a direct royalty apply to the same sale. A developer who draws licences with a royalty percentage field will hit the first inter institutional agreement and start proposing workarounds.

Ask how they would extract obligations from a signed agreement. The right answer involves structured extraction with the clause reference retained and a human verification step, not typing terms into fields. Ask to see it run on one of your own redacted agreements before contracting.

Ask what they have actually integrated. Workday, Banner and PeopleSoft are three different problems and payroll versus accounts payable routing is a fourth. Federal reporting through iEdison is another. Ask for the specific system and the specific transaction, not a general claim about APIs.

Ask who owns the code and get it in writing before kickoff. The institution should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and for a system holding licence terms and inventor payment data we would expect the university's security review as a matter of course.