Podcast Network Software: Forecasting Avails, Trafficking Campaigns and Paying Talent Without a Month of Reconciliation

Why podcast networks lose money between the ad server and the invoice

The sales director has a live deal for a national insurance brand: 2 million impressions, host read, four shows, Q4, with a hard flight window because it is tied to a product launch. She needs to know today whether the inventory exists. The answer lives in three places. The hosting platform knows historical downloads per episode. The publishing calendar, which is a Google Sheet maintained by the production team, knows which shows are on hiatus in December. And the sold inventory sits in a second sheet that the ad ops coordinator updates after each insertion order, usually within a day or two.

So she gives a number based on the last three months of downloads and a gut feel. Two of the shows underdeliver because one host took an unannounced break and the other's episode ran short of the usual two mid roll slots. In January the agency asks for a make good, which means giving away Q1 inventory that was already sellable, and the talent revenue share on the original campaign has already been paid out on booked revenue rather than delivered revenue.

That sequence is the whole business problem. Across audio and podcast projects we have delivered, the recurring pattern is a week of reconciliation at every month end, make goods that eat inventory nobody forecast, and talent disputes that surface a quarter late because the split was computed on the wrong revenue base. The money is not lost in one dramatic event. It leaks at the joins between hosting, sales, billing and talent.

Problem 1: nobody can tell you what is actually available to sell

An avail is not a download number. It is a forecast of impressions per slot type, per show, per flight window, minus what is already sold, minus what is committed to house promos and trades, adjusted for the release schedule you actually intend to run. Podcast downloads accrue on a curve, with most of an episode's delivery arriving in the first week and a long tail continuing for months, which means a campaign flighted against a back catalogue behaves nothing like one flighted against new episodes.

Megaphone and Art19 are strong hosting and ad serving platforms and they will tell you what was delivered. They are not built to hold your sales pipeline, your house promo commitments, or shows you sell but do not host, which most networks have at least a few of. Triton Digital is a serious ad server with real decisioning strength on the streaming side, and an ad server answers what to play, not what your sales team can safely promise in nine weeks.

What a custom build does: an avails engine that takes historical delivery per show and per slot, applies the planned publishing calendar including known hiatuses, subtracts sold and reserved inventory at the slot level, and returns a number the sales team can quote with a confidence range. Reservations expire, so a proposal that goes quiet for three weeks releases the inventory automatically instead of blocking it until someone remembers. This single feature is usually what stops the make good cycle, because sellers stop promising against last quarter's downloads.

Problem 2: host read and programmatic are two different businesses in one inventory pool

Host read is a production commitment. It needs a brief, talking points, brand safety constraints, a read deadline for the host, and often client approval of the script before recording. Baked in reads have no server side impression count at all, so delivery is inferred from downloads of the episodes carrying the read. Programmatic and dynamically inserted spots have a real ad server count, a floor price, and can be swapped after publication.

Treating those as one inventory type is where forecasts go wrong. A show can be sold out on mid roll host read and wide open on pre roll DAI, and a single downloads number cannot express that. Hosting platforms model DAI natively and treat host read as an afterthought, because their business is serving spots.

What a custom build does: slot level inventory typed by delivery mechanism, with separate pricing, separate approval workflow and separate delivery measurement per type. Host read campaigns carry the script approval chain and the host's read deadline as tasks with owners, so the ad ops coordinator is not chasing four hosts in a group chat the week the flight starts. DAI campaigns pull actual served impressions from the ad server by API and compare them against the guarantee daily, not at month end, so an underdelivery is visible while there is still flight left to fix it.

Problem 3: delivery, billing and what the agency will actually pay are three different numbers

The ad server says one thing. Your invoice says another because it was raised on the insertion order. The agency's own system says a third, and they will pay against theirs. Add the standard agency commission convention, net payment terms that stretch to 60 or 90 days, and any third party verification the client insisted on, and reconciliation becomes a manual matching exercise across four exports.

Hosting platforms do not carry accounts receivable, credit terms, or a dispute record. So the finance person builds another workbook, and the network's actual revenue position is only knowable to whoever maintains it.

What a custom build does: the insertion order, the delivery record and the invoice are the same object at different stages. Delivered impressions post against the IO line continuously, the invoice is generated from delivered rather than booked where the deal says so, and the shortfall calculation that triggers a make good happens automatically with a suggested make good inventory plan drawn from the avails engine. Disputes attach to the IO line with the evidence, so the conversation with the agency is about one screen rather than an email thread with attachments.

Problem 4: talent deals are bespoke and the split is computed on the wrong number

Every show on a network is on a different deal. A flat revenue share. A share after a minimum guarantee is recovered. A share that differs between host read and programmatic. A share computed on net revenue after agency commission and after a production cost recharge, or on gross for a legacy show whose contract was signed before anyone thought about it. Some shows have a floor. Some have a cap after which the network takes more.

Getting this wrong is the fastest way to lose a show. Hosts talk to each other, and a host who discovers their split was calculated on booked revenue for a campaign that underdelivered will not accept the explanation that it was a spreadsheet error.

What a custom build does: the deal becomes executable terms attached to the show, with the revenue base defined explicitly, minimum guarantee recovery tracked as a running balance, and the split calculated from delivered and collected revenue on a defined schedule. Then a talent portal shows the host their campaigns, delivery and earnings without a phone call. In our builds this halves the inbound queries within a quarter, and it changes renewal conversations because the numbers stopped being a monthly surprise.

Problem 5: measurement standards and what you can honestly promise

The IAB Podcast Measurement Technical Guidelines exist precisely because download counting used to be whatever each platform decided it was, and agencies now expect compliance as table stakes. If your network sells shows hosted on more than one platform, your reported numbers come from more than one measurement implementation, and you need to know that when you aggregate them into one campaign report.

What a custom build does: normalise at ingestion. Delivery data from each hosting platform lands in one schema with the source and the measurement basis recorded, so a campaign report across four shows on two platforms is honest about what it is aggregating. This matters more than it sounds. The moment a client's own measurement partner queries your number, you want to be able to show exactly where each figure came from, rather than defending a spreadsheet total.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape for podcast networks is this. A first release covering the show and slot inventory model, avails forecasting against a real publishing calendar, campaign scheduling with reservations, and delivery tracking against the guarantee runs $70,000 to $140,000 and ships in 12 to 16 weeks. A full revenue platform adding agency billing and receivables, make good automation, talent revenue shares with minimum guarantee recovery, programmatic reconciliation and a talent portal runs $180,000 to $450,000 phased over 6 to 11 months.

What drives cost up in this category specifically: the number of hosting platforms you pull delivery from, because each API and each measurement basis is separate work. Programmatic, if you are running open marketplace demand as well as direct, because reconciling two revenue streams against one inventory pool is genuinely hard. Multi market or multi language selling, which multiplies the avails dimensions. Branded content and live event inventory, if you sell them, because they do not fit an impression model at all. And the number of distinct talent deal shapes, which is rules work per show.

What keeps cost down: starting with direct sold host read and DAI on your top 15 shows by revenue, which is where the money and the pain both are.

Build versus buy, and when buying is the right call

Buy if you run a handful of shows on a single hosting platform and sell everything direct at a flat rate. Megaphone or Art19 plus a disciplined spreadsheet will carry you a long way, and a custom build at that size is a distraction from selling. If you are happy to be represented by a network, Acast and similar will handle sales and pay you, and that is a legitimate business choice rather than a software problem.

Build when two or more of these are true. You sell across more than about 15 shows and cannot answer an avails question in the meeting. You represent shows you do not host, so no single platform sees your whole inventory. Your talent deals differ materially and the splits are computed by hand. You have paid out make goods that were caused by forecast error rather than by anything the audience did. Or your month end reconciliation takes more than two days, which at this scale means you are paying a person to be a join between systems.

How to choose a developer for podcast and audio revenue software

Ask them to explain the difference between booked, delivered and collected revenue before you talk about features. A developer who has worked in ad tech will separate those three and will immediately ask which one your talent splits are computed on. One who treats revenue as a single number will build you a system that recreates the exact dispute you are trying to end.

Ask how they would forecast avails for a show that has been on hiatus for six weeks. The answer should involve the planned publishing calendar and the download accrual curve, not a rolling average of the last 90 days. If they reach for the rolling average, they have not seen a podcast delivery curve.

Ask which hosting and ad server APIs they have actually pulled from. Megaphone, Art19 and Triton are different integrations with different measurement bases, and there is no generic podcast API. Ask for the specific platform, not a promise about integrations in general.

Ask who owns the code, in writing, before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. For a network this matters more than usual, because your inventory and talent terms are the business, and that data should never sit inside infrastructure a vendor controls.