Why Submitted Is Not a Status: Tracking AP Portal Invoices From Sent to Confirmed

Ask a finance team how many invoices they delivered last month and you will get a precise number. Ask how many the buyer confirmed receiving, and the precision disappears.

That gap is not a reporting inconvenience. It is where receivables age without anyone collecting on them, because every downstream process — ageing, collections, forecasting — inherits the assumption that an invoice marked sent arrived. When that assumption is wrong, nothing in the system notices, and the first signal is a collections call where the buyer says they never received anything.

Why Is Submitted Not a Status?

Because submitted describes an action your team took, and the thing you need to know is a state the buyer’s system is in. Those are different facts, and conflating them is the root of the problem.

Most ERPs model invoice delivery as a flag. The invoice was emailed, uploaded or transmitted; the flag flips; the invoice enters the ageing report. That model was adequate when delivery meant posting an envelope, because postal delivery failed rarely and visibly. It is inadequate when delivery means a multi-step interaction with a buyer’s portal that can fail in several ways without returning an error.

Consider what can happen after a successful upload. The portal accepts the file but does not route it for approval because a reference is missing. The invoice is matched to the wrong PO line and enters a query queue nobody told you about. It is rejected, with the notification sent to an address that belonged to someone who left. It is approved but against a different period than you expect. Or the upload genuinely succeeded and all is well — which is the common case, and is exactly why the exceptions hide so effectively.

In every one of those scenarios, your ERP shows the same thing: sent.

What Does a Real Submission State Model Look Like?

Replace the flag with explicit states. Six is the minimum that distinguishes the situations that need different responses.

The state that earns its place is unknown. Every team has invoices whose status nobody can establish — the portal is down, the credential expired, the status page changed, the invoice simply is not visible where it should be. Without an explicit unknown state those invoices get recorded as submitted, which quietly asserts something nobody has verified. Making unknown visible converts an invisible risk into a work queue.

The second design rule matters as much: only a captured artefact advances an invoice to confirmed. A portal reference, an acknowledgement number, or an explicit status change read from the portal. Reaching the final screen of a submission wizard is not confirmation. This is the same discipline that separates a browser automation that works from one that creates silent failures, as we describe in the verification step of how an AI browser agent actually operates.

Why Do Invoices Get Silently Parked?

Silent parking is the most expensive failure mode because it produces no signal at all. The common causes are mundane.

A missing or unrecognised reference. The portal accepts the document but cannot route it without a valid PO, cost centre or contract reference, so it holds it in an unrouted state. No rejection is generated because, from the portal’s perspective, nothing failed.

An unmet approval precondition. Most common in services billing, where an invoice cannot progress until a service entry sheet is approved. The invoice waits for a condition the supplier may not know exists — the sequencing problem we cover in service entry sheet invoicing for services suppliers.

A notification sent nowhere useful. The portal did issue a rejection, to a shared mailbox nobody monitors or to a departed employee’s address. The buyer considers you informed.

A sub-entity mismatch. Large buyers run multiple entities in one portal. An invoice submitted against the wrong entity is technically present and operationally invisible.

A duplicate suppression. A resubmission is treated as a duplicate of an earlier failed attempt and discarded without notice.

What unites these is that the supplier’s system has no mechanism to notice an absence. Everything is built to react to events, and silence is not an event. That is why the control has to be a dwell-time threshold rather than an error handler.

The common thread is that none of these produce an inbound event, so no amount of diligent inbox monitoring will surface them. Each one is caught only by a control that actively goes and looks — either a check that runs before submission or a scheduled read of the portal’s own status. Designing for inbound notifications alone guarantees that the quietest failures are also the most expensive.

How Does This Gap Affect DSO and Collections?

The damage is structural rather than occasional.

Collections teams work from an ageing report. If an invoice is in the report, it is assumed delivered and the conversation is about payment. When the invoice was never actually routed for approval, that conversation is wasted: the buyer cannot pay something not in their system, and the call ends with a request to resend. Days of collections effort produce a resubmission.

Worse, the delay does not appear anywhere as a delay. The invoice ages, so DSO rises, but the cause is recorded as slow payment rather than failed delivery. Finance responds by intensifying collections, which cannot fix a delivery problem. This is the mechanism behind the invoice delivery gap that consumes working capital — the clock starts when the buyer accepts the invoice, not when you send it.

There is also a forecasting consequence. Cash forecasts built on ageing inherit the delivery assumption, so a cohort of unconfirmed invoices produces a forecast that is confidently wrong in a direction nobody can see.

What Evidence Should a Submission Produce?

Two audiences need evidence, and they want different things.

Your collections team needs enough to make a credible call: the portal reference, the submission timestamp, the status as of the last check, and who the buyer’s approver is if visible. With that, a collections conversation starts from fact rather than from hope.

A dispute or an auditor needs more: a timestamped action log, a screenshot of the submission and of the confirmation screen, the reference captured, the identity used, and the outcome. Screenshot-level evidence linked to a run identifier is what settles a disagreement months later when a buyer asserts nothing was received and your team is relying on recollection.

This is ordinary internal control thinking. The COSO internal control framework treats a control whose operation cannot be evidenced as weak regardless of how reliably it runs in practice, and guidance from IFAC and the Association for Financial Professionals points the same way. An automated submission that produces no evidence is, to an auditor, an assertion.

The bar is already familiar to anyone who has been through a service organisation audit. Under the SOC reporting framework, a control is tested on whether its operation can be demonstrated for a period, not on whether the team believes it works. Submission evidence meets that bar when each run is independently reconstructable. It is worth noting that structured delivery channels do not remove this requirement either: even under the European eInvoicing framework, a transmission acknowledgement still has to be captured and retained to prove the invoice was accepted rather than merely sent.

Notably, automated submission usually produces better evidence than the manual process it replaces. A person uploading an invoice leaves no record of what the screen showed when they clicked submit. An agent that captures screenshots at each material step leaves a complete trail — which is why getting IT security approval for AR portal automation is often easier than teams expect once the evidence model is explained.

How Should You Report and Alert on This?

Three changes make the gap manageable.

Age by state, not only by invoice date. Report how long invoices have been sitting in each state. An invoice three days old in unknown deserves attention before one thirty days old in confirmed. Conventional ageing cannot express that distinction because it has no concept of submission state.

Alert on silence. Set a maximum dwell time per state — two days in submitted, three in unknown, two in queried — and alert when exceeded. Because the expensive failures produce no event, absence of change must itself be the trigger.

Assign ownership. Every unconfirmed invoice needs a named owner, by portal or by customer. Unowned exceptions are nobody’s work and age indefinitely; the ownership problem is the same one we examine in building exception ownership across distributed account teams.

Two metrics are worth reporting to a CFO, and both are usually unmeasured: the share of invoices in unknown state, and average dwell time from submitted to confirmed. Teams measuring these for the first time generally find both materially worse than expected, which is precisely the value of measuring them. Root-cause grouping by customer, portal and error type then shows where to fix the cause rather than clearing symptoms — the same analytical move that makes rejection patterns actionable rather than anecdotal.

How Peakflo Helps

Peakflo’s invoice delivery to AP portal automation closes this gap by treating confirmation as part of delivery rather than as a separate manual check. Every submission is tracked in a single dashboard showing real-time status — submitted, approved, queried or rejected — with screenshots proving every action the agent took, so an AR analyst no longer logs into portals to find out what happened.

Because the agent reads status directly from each buyer’s portal, an invoice only moves to confirmed when a reference or status change is actually captured, which is what prevents the silent parking described above. When something does fail, the agent retries what it can and escalates the rest with a screenshot and a recommended next step, and root-cause visibility shows which customers, portals and error types drive rejections so the cause gets fixed rather than the symptom. It runs on Coupa, SAP Ariba, Tungsten, Jaggaer, Basware and in-house portals with no API and nothing required from your customer’s IT team. To see the dashboard against your own portal mix, request a demo.

Our Verdict

The binary sent flag is the most consequential piece of unexamined design in most AR stacks. It was correct for posted mail and it quietly misreports reality for portal submission, which is now how a large share of B2B invoices are delivered.

Our position: a submission is not complete until a confirmation artefact exists, and any process that advances an invoice to delivered without one is reporting an assumption as a fact. Adopt explicit states, make unknown a first-class state rather than a rounding error into submitted, and alert on dwell time rather than waiting for errors that silent failures never produce.

The reason this is worth prioritising ahead of more visible AR projects is attribution. Teams without submission-state visibility systematically misdiagnose delivery failures as slow payment, and then apply collections effort to a problem collections cannot solve. Measuring the unknown share and the submitted-to-confirmed dwell time usually reorders the improvement backlog immediately.

Conclusion

An invoice your ERP believes it delivered and the buyer has never routed for approval is the most expensive object in accounts receivable: it ages like a real receivable, consumes collections effort like a real receivable, and cannot be paid.

Start by measuring two numbers you probably do not have — what share of invoices sit in an unverifiable state, and how long submissions take to reach confirmed. Then make confirmation a requirement rather than an assumption, capture the evidence as you go, and alert on silence. The invoices that were fine stay fine; the ones that were never going to be paid surface in days instead of at the quarter’s end.

Frequently Asked Questions

Why is submitted not a reliable invoice status?

Because submitted records what your team did, not what the buyer received. An invoice can be uploaded successfully and still be parked, queried or silently rejected in the buyer’s portal while your ERP shows it as sent.

What states should invoice submission tracking use?

At minimum: queued, submitted, confirmed, queried, rejected and unknown. The unknown state matters most, because it makes the invoices nobody can account for visible instead of hiding them inside submitted.

What counts as confirmation of an AP portal submission?

A portal-issued reference or acknowledgement number, or an explicit status change visible in the portal, captured and stored. Reaching the final screen of a submission flow is not confirmation and should never advance the state.

Why do invoices get silently parked in buyer portals?

Usually because a required reference is missing or an approval precondition is unmet, so the portal accepts the upload but does not route it for approval. No rejection is issued, so the supplier has nothing to react to.

How does submission visibility affect DSO?

Invoices stuck between sent and confirmed age without anyone collecting on them, because collections works from an ageing report that believes they were delivered. The delay is invisible and therefore uncontested.

Why capture screenshots of invoice submissions?

Because a timestamped screenshot plus a portal reference settles a dispute when a buyer says no invoice was received. Without run-linked visual evidence, the conversation becomes one team’s recollection against another’s.

How often should submission status be polled?

Daily for high-volume portals is usually sufficient, with tighter intervals near month-end cut-offs. The requirement is that polling is scheduled rather than triggered by someone remembering to look.

What is the difference between queried and rejected?

A rejection returns the invoice and requires resubmission. A query holds it pending supplier clarification. Queries are more dangerous because they look inactive rather than failed and often sit unnoticed for weeks.

How should invoices be aged for submission tracking?

By time spent in each submission state rather than by invoice date alone. Conventional ageing cannot distinguish an invoice awaiting buyer approval from one that never reached the approval queue.

Can submission tracking be automated without a portal API?

Yes. An AI browser agent can log into the portal, read the current status, capture the reference and a screenshot, and update the state, which is exactly the manual checking an AR analyst performs today.

What metric exposes silent submission failures?

The share of invoices in unknown state, and average dwell time between submitted and confirmed. Both are normally unmeasured, and both tend to be far larger than finance leaders expect on first measurement.

Who should own unconfirmed invoices?

A named owner per portal or customer, with an escalation path once dwell time is exceeded. Unassigned unconfirmed invoices are nobody’s work, which is why they age until a collections call surfaces them.