How to Structure a 90-Day POC for Invoice Delivery Automation

Ask a finance leader how their last AI pilot went and you will frequently get a hedged answer. It worked, mostly. The demo was impressive. The team liked it. There were some issues with a couple of the harder cases. They are still deciding.

That is the signature of a proof of concept that was never designed to produce a decision.

The problem is almost never the technology. It is that the pilot was scoped to demonstrate — to show the thing working — rather than to falsify, to genuinely test whether it holds up under the conditions that actually matter. A pilot that cannot fail cannot inform a choice, and a pilot scoped to the easy cases will always succeed while leaving the real question untouched.

This is a practical framework for designing an invoice delivery automation POC that ends in a clear yes or no. It deliberately does not cover total cost of ownership modelling, which is a separate exercise handled in AI agent platform pricing and TCO analysis — the focus here is purely on evaluation design.

Why 90 Days?

The number is not arbitrary, and it is not simply a round quarter.

Invoice delivery is a cyclical process. Volume arrives in concentrated bursts tied to billing cycles rather than flowing evenly. A 30-day pilot may capture only one such cycle, which tells you how the system performed once — not whether it performs consistently.

Three things need multiple cycles to become visible:

Consistency across cycles. Did cycle three go as well as cycle one, or did something degrade as volume accumulated?

Learning trajectory. Agentic systems should improve as they accumulate learned behaviour from operator corrections. That improvement curve is the single most informative signal in the whole pilot, and it is invisible in a single cycle. The mechanics of what does and does not improve are covered in how AI browser agents learn from corrections.

Real-world disruption. Over 90 days you will encounter a portal outage, a client changing their requirements, an unusual invoice type, and a key person on leave. How the system and the vendor handle those is far more predictive of live operation than a clean run.

Ninety days is roughly the shortest window that reliably contains all three. Substantially longer pilots tend to lose organisational momentum without adding much information.

What Should Be In Scope?

This is where most pilots go wrong, and the error is consistent: scoping to the easy cases.

It is a natural instinct on both sides. The vendor wants a clean result. The buyer wants a low-risk start. So the pilot covers one well-documented major platform with high volume and stable rules — and it succeeds, proving something nobody genuinely doubted.

A useful scope is deliberately uncomfortable.

Choose Portals by Difficulty, Not Convenience

Include three destinations spanning the difficulty range:

The middle row is the one buyers most often omit and the one that matters most. Every vendor supports the major platforms. Capability differences show up in the long tail — the spreadsheets, the client-built portals, the strict-format email intakes described in automating the long tail of client portals. If the pilot avoids those, it has tested the commoditised part of the offering.

Choose Volume for Statistical Meaning

A pilot handling 30 invoices proves very little. If two fail, is that a 7% failure rate or bad luck? There is no way to tell.

Aim for several hundred submissions across the pilot period. That is generally enough to distinguish a real success-rate difference from normal variation, and — importantly — enough for the exception rate to show a trend rather than a single noisy figure.

Include Your Messy Data

Pilots are frequently run on a clean subset of invoices. This is a mistake, because clean data is not what the system will face in production.

Include the invoices with unusual line items, the clients with inconsistent reference conventions, the credit notes, and the resubmissions. If the pilot only handles well-formed invoices, it has not tested the exception path — which is precisely where the value of automation is decided.

What Are Good Success Criteria?

Criteria must be numeric, measurable from system data, and agreed before the pilot begins. If they are written afterwards, they will be written to fit whatever happened.

The Core Measures

Two of these deserve particular emphasis.

Exception rate trend is more informative than exception rate. A system starting at 20% exceptions and falling to 8% is behaving as an agentic system should. One holding flat at 12% is not learning, and that is a genuine finding — though it may equally indicate that your residual failures are source-data problems that no delivery system can learn away.

Human minutes per invoice is the metric most often omitted and the one that determines actual ROI. A system with a 95% success rate that requires someone to review every submission has not saved anything. Measure the human time honestly, including monitoring and exception handling, not just the submissions that ran untouched.

Define Failure Explicitly

The single most valuable sentence in a POC agreement specifies what result means no.

Something of the form: “If first-time submission success is below X%, or human effort per invoice exceeds Y minutes, at the end of the pilot period, the engagement ends and fees are waived.”

Without this, an ambiguous result becomes a negotiation. The vendor points to what worked, the buyer points to what did not, and the decision drifts for months. A pre-agreed failure threshold converts the outcome into an arithmetic question.

Should a POC Be Free?

Buyers frequently push for a free pilot, and vendors frequently resist. Both positions are reasonable, and the standard compromise is usually the right answer.

A genuinely free POC is uncommon for implementation-heavy automation because real work is required up front — integration, workflow configuration, portal onboarding, credential setup. A vendor absorbing that entirely for every prospect is either pricing it into their other customers or is not doing it properly.

The workable structure is a paid pilot with fees credited against the contract. If the buyer proceeds, the pilot cost is applied as credit and the effective cost is zero. If the buyer does not proceed, the vendor has recovered their implementation cost.

This aligns incentives well. The vendor is motivated to succeed, since credited fees plus a contract beat retained fees. The buyer’s downside is capped and known. And the modest cost filters out pilots nobody was ever seriously going to buy — which is good for both sides, since an unserious pilot wastes the buyer’s time as much as the vendor’s.

Where buyers should push is not on the fee but on the exit terms:

• What specifically happens to fees if success criteria are not met?
• Who owns the configuration built during the pilot?
• How is data returned or deleted on exit?
• What notice is required to end the engagement?
• Does pilot pricing set a precedent for contract pricing, or are they independent?

How Should You Run It?

Run in Parallel, At Least Initially

Keep the manual process running alongside the automation for at least the first cycle.

The benefit is twofold. You get a direct baseline comparison on identical invoices, which is far more credible than comparing against historical averages. And you protect billing continuity — if the automation underperforms, invoices still go out.

The cost is duplicated effort during the pilot. That is a real cost, and it is normally worth paying for a clean comparison and controlled risk. Most teams taper parallel running after the first cycle once confidence builds.

Staff It Properly

A pilot needs three roles from the buyer’s side:

An executive sponsor who owns the decision and can unblock credential provisioning and IT dependencies.

An operational lead who works with the system daily. This is the most important role and the one most often under-resourced. A pilot evaluated only by people reading reports produces a technical verdict with no insight into whether the team will actually adopt it.

An IT contact for the integration work, even where the delivery layer is largely no-code.

Hold Scope Constant Across Vendors

If you are piloting more than one vendor — increasingly common — do not let each design their own pilot. They will each choose scope favourable to their strengths, and the results will not be comparable.

Define the portals, the invoice sample, the measures, and the thresholds yourself, and give the same specification to every vendor. This is more work up front and it is the only way to get a comparison that means anything.

What Should You Learn Beyond the Metrics?

The numbers answer whether the system works. Ninety days of close contact answers something equally important: what this vendor is like to work with.

Pay attention to:

• Response time when something breaks. It will break. How quickly and how transparently did they respond?
• Honesty about limitations. A vendor who says “that case will need manual handling” is more trustworthy than one who claims everything is covered. The limitation boundary is real for every product.
• Who actually shows up. Are the people delivering the pilot the ones you will work with afterwards, or a specialist pre-sales team?
• How new destinations get added. During 90 days you will likely need to add one. That is a free preview of your ongoing onboarding experience — the dynamic examined in portal onboarding velocity as a revenue constraint.
• Whether your team’s corrections change anything. If operators fix the same issue repeatedly with no improvement, the feedback loop is not functioning.

How Peakflo Structures Evaluation Pilots

How It Works

• Phase-one scoping. Pilots are structured as a defined first phase covering a subset of portals and an agreed delivery volume, rather than an open-ended trial.
• Fees credited to contract. Pilot costs are applied as credit against the overall contract value if you proceed beyond the pilot period.
• Mixed-difficulty scope by design. Peakflo encourages including a bespoke or unusual destination alongside standard platforms, because that is where capability differences are genuinely revealed.
• Live dashboard from day one. Submission results, exception queues, and rejection reasons are visible throughout the pilot rather than summarised in a closing report, so you measure from system data rather than vendor narrative.
• Forward-deployed engineering support. Engineers configure portal workflows during the pilot, including novel destinations built from screen recordings.
• Parallel-running friendly. Pilots are designed to run alongside existing manual processes so billing continuity is never at risk.
• Measurable learning curve. Exception rates are tracked across the pilot period so the improvement trajectory is observable rather than asserted.

What Makes This Different

The scoping recommendation is the substantive point. It would be commercially easier to propose a pilot covering only high-volume standard platforms, where results are predictably strong. Peakflo’s position is that such a pilot does not tell a buyer what they need to know, because every credible vendor performs well there. Including a genuinely hard destination risks a less flattering result and produces a decision the buyer can actually rely on.

Our Verdict: When Is a POC Worth Running?

Run a POC If

• Your portal estate includes destinations that are genuinely unusual.
• Your source system is non-standard and integration is unproven.
• The contract value justifies a structured evaluation.
• You are comparing multiple vendors and need comparable evidence.
• Internal stakeholders need proof rather than references.

Skip Straight to Implementation If

• Your portals are entirely standard platforms with well-documented support.
• Your volume is modest and the contract value does not justify the overhead.
• You have strong references from closely comparable organisations.
• Speed matters more than certainty and the downside of a wrong choice is contained.

Conclusion: Design It to Fail, or It Will Not Tell You Anything

The instinct when designing a pilot is to maximise its chance of success — pick the straightforward portals, use clean data, keep the scope contained. That instinct produces pleasant pilots and useless evidence.

A proof of concept is an experiment, and an experiment is only informative if it could have come out the other way. Include the difficult destination. Use the messy invoices. Write down the number that means no, before you start. Hold the scope constant across the vendors you are comparing.

Ninety days is enough time to learn what you need. But only if the pilot was built to test something rather than to show something.

Peakflo scopes phase-one evaluations with success criteria agreed up front and pilot fees credited against the contract. Schedule a demo to scope one against your own portals.

Frequently Asked Questions

How long should a POC for invoice delivery automation run?

Around 90 days is the common standard because it spans several complete billing cycles. That matters because invoice delivery is cyclical, and a shorter window may capture only one cycle, which is not enough to observe whether the system improves as it accumulates learned behaviour.

Should a proof of concept be free?

A genuinely free POC is uncommon for implementation-heavy automation because real integration and configuration work is required. The more usual arrangement is a paid pilot where the fee is credited against the contract if the buyer proceeds, which aligns both parties without asking the vendor to absorb the full setup cost.

What should be in scope for an invoice delivery POC?

Two or three portals covering different difficulty levels, and enough invoice volume to be statistically meaningful. A well-designed scope includes one high-volume standard platform, one bespoke or unusual destination, and enough submissions that success and failure rates are not attributable to chance.

What are good success criteria for a finance AI POC?

Criteria should be numeric, measurable from system data, and agreed before the pilot starts. Useful examples include successful first-time submission rate, average time from invoice availability to accepted submission, proportion of exceptions requiring human intervention, and whether that proportion declines across the pilot period.

Why do most proofs of concept end inconclusively?

Because they were designed to demonstrate rather than to falsify. Scope is set to the easiest cases, success criteria are qualitative, and no one defined in advance what result would constitute failure. A pilot that cannot fail cannot inform a decision.

Should the hardest portal be included in a POC?

At least one difficult destination should be included. Testing only well-documented major platforms proves the easy case and leaves the real question unanswered, since the long tail of unusual destinations is typically where manual effort concentrates and where vendor capability actually differs.

What exit terms should a POC agreement include?

The agreement should state what happens if success criteria are not met, including whether fees are refunded or waived, who owns any configuration built during the pilot, how data is returned or deleted, and the notice period for ending the engagement. Ambiguity here is what turns an inconclusive pilot into a drawn-out negotiation.

How much invoice volume is needed for a meaningful POC?

Enough that outcome rates are not dominated by chance. A few hundred submissions across the pilot period is a reasonable target, since that is sufficient to distinguish a genuine success rate difference from normal variation and to observe whether exception rates decline over time.

Who should be involved in a POC from the buyer’s side?

An executive sponsor who owns the decision, an operational lead who works with the system daily and judges whether it genuinely helps, and an IT contact for integration. Running a pilot without daily operational involvement produces a technical result with no insight into whether the team will actually adopt it.

How should buyers compare competing POC offers?

By holding scope and criteria constant across vendors rather than accepting each vendor’s proposed design. If different vendors pilot against different portals and different measures, the results are not comparable and the decision defaults to whoever presented most persuasively.

What should be measured during an invoice delivery pilot?

First-time submission success rate, time from invoice availability to accepted submission, exception rate and its trend over the period, human minutes spent per invoice, accuracy of rejection-reason capture, and reliability of confirmation capture. Trends matter as much as absolute values.

Should a POC run in parallel with the existing manual process?

Usually yes, at least initially. Parallel running gives a direct baseline comparison and protects billing continuity if the automation underperforms. The cost is duplicated effort during the pilot, which is normally an acceptable trade for a clean comparison and controlled risk.