Stop Treating the AP Portal as a Delivery Problem
Why the AP Portal Needs to Be Handled Better by AR Software: Our Viewpoint Series
Ask most finance teams how their invoices reach a customer, and they'll describe a delivery choice: email, EDI, or a portal, depending on what the buyer wants. That framing is the problem. Email and EDI are transport. A portal is a gate - and gates say no.
An invoice sent by email either arrives or it doesn't; a delivery failure is apparent and immediate. An invoice submitted into a customer's AP portal can be rejected silently, days later, for reasons the supplier never sees until someone goes looking. Treat that as a delivery problem and you'll build processes that confirms the file was uploaded. Treat it as what it actually is - a compliance checkpoint with its own failure modes - and you build something that tells you whether the invoice was accepted. Those are very different products, and right now, most of the market builds the first one.
Monk, the AI-native AR platform, has been making a version of this argument with the benefit of their 600 third-party portal automations (and counting), and we think they're substantially right: for a large share of enterprise buyers, an invoice that isn't inside the portal effectively doesn't exist, no matter how promptly it was emailed. Where we'd push further than the vendor argument is on what follows from that. The industry's answer so far has mostly been to compete on portal coverage. A vendor plugged into every portal a customer needs can still leave finance with no idea whether invoices are landing clean. Coverage is a distribution claim. Acceptance is a quality claim. Buyers evaluating this category should be asking for both of these numbers.
What is an AP Portal?
An AP portal is a web application a buying organisation runs so its suppliers submit invoices directly into the buyer's own accounts payable workflow, rather than emailing a PDF and hoping someone keys it in. Coupa, SAP Business Network (formerly Ariba), and Workday-hosted supplier portals are the familiar large-enterprise examples, but plenty of mid-market and public-sector buyers run bespoke or smaller-vendor portals too. For the supplier, this isn't optional - if a customer mandates portal submission, that's the only channel that starts the payment clock, regardless of what else the supplier sends.
The scale of this is easy to underestimate from outside a finance team. One AR vendor's own data puts the proportion of enterprise invoices that must go through a portal, rather than being paid from an emailed document, above nine in ten. If that figure is even roughly right across the market, portal submission isn't an edge case in enterprise AR - it's closer to the default path.
What makes an AP portal submission fail?
Portals reject invoices for reasons that have nothing to do with whether the invoice is correct in any meaningful sense. The most common causes we see referenced consistently across AP and AR sources are:
PO mismatches: a purchase order reference that's missing, wrong, or doesn't line up with what the buyer's system expects.
Data mismatches: the supplier's record of a customer's name, address, or tax details doesn't match what's stored on the buyer's side, even when both are technically correct.
Format and specification drift: each portal has its own technical requirements, and these change without warning, so a submission method that worked last quarter can start failing this one with no notice.
Missing compliance documentation: tax data, W-9 equivalents, or other supporting paperwork the portal expects before it will accept anything.
None of these is a delivery failure. The file reaches the portal every time. What fails is a rules check the supplier usually can't see until after the fact - and unlike a bounced email, a portal rejection doesn't automatically land in anyone's inbox. It sits there. This is the mechanism behind the "silent ageing" that shows up in DSO reports with no obvious cause: the invoice isn't late because the customer is slow to pay, it's late because it was never actually accepted.
A day in the life of a rejected invoice
Abstract failure modes are easy to agree with and easy to forget. Here's what one of them actually looks like in a timeline, using a composite of the patterns described above rather than any single real case.
Day 1. An invoice is issued and submitted into the customer's portal on time. As far as the supplier's own systems are concerned, the job is done - the invoice has been sent.
Day 2. The portal rejects it. The PO reference on the invoice doesn't match the one on the buyer's purchase order, perhaps because the buyer amended a line item after issuing it. The rejection generates a message inside the portal. It does not generate an email, a Slack alert, or anything else that lands in front of the person who sent the invoice. As far as the supplier's AR system is concerned, nothing has changed - the invoice still shows as "sent."
Days 3–29. Nothing happens, because nothing is visibly wrong. The invoice ages on the AR aging report exactly the way a normal unpaid invoice would. Around the three-week mark, standard dunning kicks in - a polite reminder, then a firmer one, both addressed to a customer who has no outstanding action to take, because from their side the invoice was never accepted in the first place. The reminders go unanswered, which reads to the AR team as a slow or unresponsive payer.
Day 30. The account gets flagged for manual review because it's now noticeably overdue against terms. Someone on the AR team logs into the customer's portal directly - the first time anyone has actually looked - and finds the rejection notice sitting there, dated day 2, giving the mismatched PO reference as the reason.
Day 31. The invoice is corrected and resubmitted. It's accepted the same day.
Day 46. The invoice is paid, fifteen days after acceptance - inside the customer's normal payment terms.
Reported on a standard AR dashboard, this invoice took 46 days to collect, which looks like a customer that pays slowly. The real story is a submission that failed after two days, a detection gap of twenty-eight days, and a customer that then paid exactly on time. Nothing about the customer's behaviour caused the delay. A large percentage of the elapsed time was the invoice sitting in a state nobody was watching - and that's the part a single DSO figure can't show you, because it wasn't designed to distinguish "the customer is slow" from "we didn't know there was a problem."
How AI AR software is reducing AP portal submission failures
The gap in the example above - a rejection sitting unseen for twenty-eight days - is a great example of the gap AI-native AR platforms are now built to close, and it's worth looking at what that actually means mechanically rather than taking the marketing at face value.
Monk, which has published more detail on this than most of its peers, reports submitting invoices into more than 600 corporate AP portals and completing 87% of those submissions without a person involved. What is more important than the automation itself is what happens when a submission is rejected: rather than the rejection sitting silently inside the portal until someone logs in to check, the platform returns the rejection reason directly to the invoice record. In terms of the worked example above, that's the difference between day 2 and day 30 - the detection gap collapses to roughly zero, because nobody has to go looking for a problem they don't know exists. Monk cites a customer, Profound, that automated submissions into Coupa, Ariba, and eleven bespoke Fortune 500 portals and grew cash on hand by 122% in its first month.
The broader point stands independent of any one vendor's figures. Where AI genuinely changes the economics here isn't the submission itself - pushing a file into a portal was never the hard part - it's the pattern-matching underneath: recognising that a given portal rejects a certain field format, that a specific customer's PO references drift in a predictable way, or that a rejection reason maps to a fix that's been applied a hundred times before.
Why credential management is so hard
Set aside rejection rules for a moment and consider the more basic problem of just being able to log in. Every portal is a separate system with its own username, password, and increasingly its own two-factor device. A supplier serving a couple of hundred enterprise customers can end up maintaining logins across thirty or forty different portals simultaneously, none of which talk to each other.
That's a headache on a good day. It becomes a real problem at the edges: when someone on the finance team leaves, every one of those credentials - and, for portals with 2FA tied to a device, the device registration too - needs to be found and deactivated individually. There's rarely a single admin console spanning all of it, because these are the buyer's systems, not the supplier's. The result is that credential management for AP portals tends to fall into the gap between IT and finance - too operational for IT to prioritise, too technical for finance to own outright — and it's exactly the kind of unglamorous problem that doesn't get fixed until it causes a missed payment or a security incident.
How modern AR software handles AP portal submission
Approaches in the market roughly split into three camps, and it's worth understanding what each one actually solves.
Coverage-first platforms. Monk, HighRadius, and Versapay all now advertise integrations into 500–600+ AP portals, and treat portal submission as a native part of the invoice-to-cash workflow rather than a bolt-on. Monk's specific claim is that it submits the large majority of invoices without human involvement and, when a portal does reject one, attaches the rejection reason back to the invoice record so a collector isn't starting from zero. That last part, surfacing why something failed, not just that it did, is the detail that actually addresses the problem we're describing here, and it's the one worth pressure-testing with any vendor claiming portal automation.
Delivery-infrastructure platforms. Billtrust's strength is invoice presentment and payment acceptance across multiple channels (email, portal, print) which is useful for portal-heavy customer books, but by design it's optimised around getting the invoice distributed, which is closer to the delivery framing we're arguing against.
Collaboration-first platforms. Versapay's core pitch is a shared workspace between buyer and supplier AR/AP teams, which helps with visibility and dispute handling once an invoice is in a portal, but that's a different problem to preventing the rejection in the first place.
None of this is a case for one platform over another - that's not the point of this piece. It's a case for asking a sharper question than "how many portals do you connect to." The number that matters is what happens after the file lands.
What finance teams should measure
This is where we'd ask finance teams to change what's on the dashboard, not just what's in the toolkit.
Most AR reporting collapses everything between "invoice issued" and "cash received" into a single days-sales-outstanding figure. That number can't tell you whether an invoice is stuck because a portal rejected it on day two, or because a customer is genuinely slow to pay on day forty-five - and those require completely different fixes. Two figures worth pulling out on their own:
Acceptance rate: the proportion of portal submissions accepted first time, by portal and by rejection reason. Not submitted; accepted.
Time-to-acceptance: measured separately from time-to-payment, so a submission bottleneck doesn't get buried inside a collections number.
A practical way to see whether this is already a problem: pull twenty recent invoices and timestamp every stage - issue, submission, acceptance, payment. If most of the delay sits before acceptance, no amount of chasing the customer will fix it, because the customer hasn't actually seen the invoice yet in any sense that matters. If the delay is after acceptance, that's a genuine collections issue. Most finance teams, when they try this exercise, find they can't produce an acceptance rate or a time-to-acceptance figure from their current reporting at all - and that gap is itself the finding worth acting on.
That's the opinion we'd defend: the AP portal isn't a delivery channel that occasionally misbehaves. It's a distinct stage in the AR cycle with its own failure modes, its own operational burden, and (if finance teams start measuring it separately) its own fixable metric. Software that reduces it to "sent" is answering the wrong question.
