Aggregate Spend and Transparency Software: How Do You Attribute Every Transfer of Value to the Right Practitioner Before It Is Published?

Why transparency reporting breaks on packaged tooling

It is late February and the compliance analyst has a spreadsheet with 61,000 rows. Column A is a name as typed by a rep into an expense report. Some rows say Robert Chen MD. Some say Chen, Bob. Some say the practice name because the rep expensed a lunch to the office. Two hundred rows are a teaching hospital that has to be attributed to the institution rather than a person. Forty rows are a speaker fee where the contract names one physician and the wire went to their professional corporation. The submission deadline is fixed, the data becomes a public record with a named individual attached, and every error becomes something the company has to correct in public.

The stack is usually an expense platform, a meeting logistics vendor exporting attendee sign-in data, a grants management system, sample accountability from the field, contract and payment records from finance, and a speaker bureau tool. Then a reporting product such as MediSpend, Porzio GST or an IQVIA service sits at the end of that chain. Those products are competent at the rules engine and the submission format. They are not the reason the project is hard.

The reason it is hard is that none of the source systems knows who a practitioner is. They know a name string typed by a person under time pressure. The reportable record requires a validated identity with a national provider identifier, a state licence, a specialty and a practice address. The distance between those two things is where the entire compliance risk sits, and it is work no rules engine performs for you.

Problem 1: identity matching is the whole accuracy problem

Every downstream calculation is correct or incorrect based on one decision: is this name string the same human as that record in the provider registry. Get it wrong in one direction and you publish a payment against a physician who never received it, which produces a dispute from a named professional and a correction in a public dataset. Get it wrong in the other direction and the payment goes unreported, which is the finding you actually fear.

Packaged transparency products do match, and they will import a provider reference file. What they generally do not give you is a tunable matching engine you can inspect: candidate generation, weighted comparison across name, credential, specialty, address and historical interaction, a confidence score you can threshold, and a stewardship queue where a human resolves the ambiguous middle band and the decision is remembered forever. Without that, matching is a black box you cannot defend in an audit and cannot improve when it is wrong.

A custom build makes the practitioner master a real asset the company owns. Records carry identifier, licences by state, specialty taxonomy, practice affiliations over time and every alias ever seen in a source system. New source rows match against it, high confidence matches auto-resolve, the ambiguous band goes to a steward, and every manual resolution becomes a permanent alias so the same lunch receipt never needs a human twice. Aliases are the compounding asset here. By the second reporting year the queue is a fraction of what it was, and that is the effect no vendor licence gives you because the aliases are not yours in their system.

Problem 2: a meal is one receipt and many attributions

A rep buys lunch for a practice. The receipt is one number. The reportable records are a per-attendee value derived from a sign-in sheet that may be a photograph of a paper form, may include staff who are not covered recipients, may include two people with the same last name, and may be missing someone who ate. Speaker programmes are worse: an honorarium, travel, lodging and meals for the speaker, plus meals for attendees, all from different vendors with different identifiers for the same event.

This is where the packaged tools push the work back to services. The event exists in the meeting logistics vendor, the payment exists in finance, the attendance exists on a sheet, and stitching those into one event object is manual reconciliation performed by analysts. Because the reconciliation is manual, it happens once a year under deadline pressure rather than continuously.

A custom build makes the event the object and everything else an attachment to it. The meeting vendor feed creates the event. Finance payments attach by purchase order or contract reference. Attendance attaches from the sign-in capture, and this is one place document extraction genuinely earns its cost: photographed sign-in sheets become structured attendee rows with names, credentials and signatures, routed to a steward when confidence is low. Attribution rules then split the value per covered attendee, exclude non-covered staff, and hold the audit trail showing exactly how one receipt became fourteen reportable records.

Problem 3: disputes arrive from named professionals with a clock attached

Open Payments gives covered recipients a review and dispute window before data is published, and physicians do use it. A dispute is not an abstract data quality ticket. It is a specific person saying they did not receive that payment, and your answer has to be produced quickly, must be traceable to source evidence, and may require a correction that itself becomes part of the public record.

Packaged products track disputes as records. What they rarely give you is the thing that resolves a dispute in ten minutes rather than three days: a single view that goes from the published line back through the attribution rule, back through the event, back to the original expense line, the sign-in sheet image and the contract, with every transformation visible. Without that lineage, resolving a dispute means an analyst emailing three system owners.

A custom build stores lineage as a first-class structure, not as a log. Every reportable record points at its inputs and the rule version that produced it. When a physician disputes, compliance opens one screen, sees the receipt, the sign-in sheet and the rule, and either corrects with a documented reason or responds with evidence. The same lineage is what makes a restatement safe, because you can recompute a prior period under the rules that applied then rather than the rules you have now.

Problem 4: every other country has its own regime and its own definition

The US programme is one of several. European disclosure under the EFPIA code, French transparency requirements, medtech-specific codes and various national schemes each define covered recipients differently, treat organisations differently, handle consent differently and publish in different formats. Several require individual consent to name a recipient, which the US programme does not.

This is where multinational teams discover that their packaged tool was scoped as a US product with international modules. Each new country becomes a configuration project, and the country teams meanwhile maintain their own local spreadsheets because their definitions do not fit the global model. You now have two sources of truth and a reconciliation nobody owns.

A custom build separates the transaction from the regime. One canonical transfer of value record captures what happened. Regime adapters then decide, per country, whether that record is reportable, what category it falls into, whether consent exists, whether the recipient is an individual or an organisation, and what format it exports in. Adding a country becomes writing an adapter against a stable core rather than reshaping the core.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a focused first release covering source ingestion, the practitioner master with confidence-scored matching, stewardship queue and US reporting output runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding event attribution with sign-in extraction, research payment linkage, a physician review portal, restatement handling and additional country regimes runs $200,000 to $450,000 phased over 6 to 12 months.

What drives the number up in this category specifically:

• Number of source systems, because each one has its own idea of what a recipient identifier is and none of them agree
• Number of countries, since each regime is a distinct adapter with distinct consent and recipient rules
• Historical data quality, because migrating several years of prior submissions with their aliases is what makes year one accurate rather than year three
• Research payments, where linkage to principal investigator, study and institution is a separate data model from commercial spend
• Whether you want the physician-facing review portal, which adds authentication, identity proofing and a support path for people who are not your employees

What keeps it down: doing the practitioner master and the matching engine first, alone, before any reporting output. That is the asset. Everything else is comparatively mechanical once identity is solved.

Build versus buy, and when buying is the right call

Buy if you report in one country, have one expense system, run few or no speaker programmes, and your annual volume is in the hundreds rather than the tens of thousands. MediSpend and Porzio GST will handle that, the rules maintenance is genuinely useful, and building would be an expensive way to reach the same submission file.

Build when the shape changes. Two or more of the following usually settle it: you report in three or more jurisdictions with materially different definitions, you run high-volume speaker and advisory programmes where event attribution is the bulk of the work, your matching accuracy is unknown because the engine is opaque, you have had disputes you could not answer within a day, or you have acquired a company and now maintain two parallel processes.

Our honest position: the licensed products are not the problem in most failed transparency programmes. The problem is that the hard part, identity and attribution, is treated as a services engagement repeated every year rather than as an asset that improves. A build is worth it when you decide that asset belongs to you.

How to choose a developer for transparency reporting software

Ask them to explain their matching approach before anything else. You want to hear candidate generation, weighted scoring across multiple attributes, an explicit confidence threshold, a human stewardship band and permanent alias capture. If the answer is a fuzzy string comparison with a percentage, they will hand you a system whose accuracy you cannot defend.

Ask how lineage works when a physician disputes a published payment. The right answer traces a reportable record back through rule version, event, attendee attribution and original source line, on one screen. Anything less means your compliance team is still emailing system owners under a clock.

Ask what happens when you have to restate a prior period. The system must be able to recompute under the rule versions that applied then, not the current ones, and show the difference. Developers who have not built versioned rules will discover this in production.

Ask about the practitioner registry sources they have actually worked with, and whether they understand teaching hospital attribution and payments routed through professional corporations. These are the specific edge cases that generate disputes, and someone who has done this names them without prompting.

Ask who owns the code and get it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the code is yours from the first commit, and the practitioner master and alias set you build is your data, not a vendor's.