How to Tell if an Invoice Is Stuck in an AP Portal, and What to Check
An invoice is stuck in an accounts payable portal when it was submitted but never reached a received or approved state, and nobody was told. There is no bounce and no error email. The first signal is usually that the invoice is old. At Monk we submit invoices into more than 600 corporate AP portals, and the single most useful habit we have is checking that each submission reaches a received state. Uploading it is not the end of the job.
This post covers how to check, what the common failure points are, and how to tell a stuck invoice apart from a slow payer. The difference matters, because chasing a customer for an invoice their system never accepted does not produce payment.
How do you know an invoice is stuck rather than unpaid?
Log into the portal and look at the invoice status there. Your own sent folder cannot tell you.
A submitted invoice moves through states inside the buyer's system. It is received, then matched against a purchase order and a goods receipt, then approved, then scheduled in a payment run. If the invoice is not visible at all, or sits at received with no match, it is stuck. If it shows as approved and scheduled, it is not stuck and the delay is a payment timing question.
Your own records cannot tell you this. An invoice marked as sent in your ERP only proves it left your side.
What are the most common reasons an invoice never reaches received?
Six causes account for most of what we see.
| Cause | What it looks like | Where to check |
|---|---|---|
| Purchase order mismatch | Invoice visible but never matched | PO number and line items against the buyer's PO |
| Missing required field | Submission appears to fail with no clear reason | The portal's required field list, which changes between releases |
| Wrong file format | Upload rejected at the point of submission | The buyer's stated format and attachment rules |
| Supplier record deactivated | Login works, submission does not | Your supplier record status, often after a buyer merger |
| Stale remit-to details | Invoice approved but payment goes nowhere useful | Remit-to address and bank details held in the portal |
| Login or 2FA failure | Nobody submitted it at all | Whether the submission happened at all |
The last one is more common than people expect it to be. Two factor authentication on a shared portal login is a frequent point of failure, and when it blocks a submission the invoice never enters the buyer's system.
Why do these failures go unnoticed?
Because portals are built around the buyer's workflow. The supplier is a secondary user.
The buyer's accounts payable team gets notified when something needs their attention. The supplier usually does not. A rejection often lands in a portal message centre that nobody on the finance team logs into, and a required field added in a quarterly release changes the rules without telling anyone who submits against them.
Our own data puts edge cases like these at 39% of the slowdown in cash flow. That share sits in a step most teams never measure.
What should you check, in order?
Work from the outside in. This takes about five minutes per invoice.
- Confirm the submission happened. Check the portal's submitted or sent list rather than your own ERP.
- Check the invoice status inside the portal. Received, matched, approved, or absent.
- If it is absent, check whether your supplier record is still active and whether the login worked.
- If it is received but not matched, compare the PO number and line items against the buyer's purchase order.
- Check the portal message centre for a rejection notice.
- Check the remit-to details held on file, especially if anything changed on your side.
- Only after all of the above, follow up with the customer.
That last point is the one worth holding to. If you contact a customer before checking the portal, you are asking them to act on something their system never took in.
How do you stop this happening repeatedly?
Two things, one process and one system.
The process one is a portal register. Ours started as a tracking sheet listing which customers require portal submission, the exact portal each uses, and the specific requirements for each: deadlines, file format, and any extra fields such as vendor codes. It is the difference between eleven separate incidents and one fixable pattern, because the same buyer usually rejects for the same reason.
The system one is submitting earlier than the due date. If a submission is made a few days ahead, a rejection still leaves room to fix and resubmit before the invoice is late. Submitting on the due date means any rejection is automatically a late invoice.
How does Monk handle this?
Monk submits invoices into more than 600 corporate AP portals, and 87% of those submissions happen without a person involved. That covers login, two factor authentication, upload, submission, and status tracking. When a portal flags something that needs a judgement call, it comes back as a review task rather than sitting unseen in a portal message centre.
The remaining 13% is the part that needs a person, and the work there is specific rather than general: one buyer's portal at a time, one validation rule at a time.
Across the $2B+ in receivables we manage, 92% of enterprise invoices have to be submitted through a customer's AP portal rather than being paid from an emailed invoice. Customers see a 40% average reduction in DSO, and go-live takes one to three days. Monk is SOC 2 Type II compliant.
What to read next
If you want the wider picture on why portals reject invoices, see why AP portals reject your invoices. For the automation options, see best AP portal automation software. For how the two factor problem specifically plays out, see AP portal access and 2FA.
Frequently asked questions
How long should I wait before checking a portal submission?
Check that it shows as received within one business day of submitting. Waiting until the due date removes the time you would need to fix a rejection.
Does a portal always notify you when an invoice is rejected?
No. Some portals post a rejection to a message centre inside the portal with no email, which is why rejections sit unnoticed for weeks.
What is the difference between received and approved?
Received means the buyer's system has the invoice. Approved means it has been matched to a purchase order and cleared for payment. An invoice can sit at received indefinitely if the match fails.
Can an invoice be stuck even if the portal shows it as submitted?
Yes. Submitted describes your action. Received describes the buyer's system accepting it. Those are two different states and only the second one leads to payment.
Who should own portal checks, AR or the account owner?
AR, with an escalation path to the account owner. The check is procedural, but resolving a purchase order mismatch usually needs someone who knows the commercial relationship.
Does resubmitting a rejected invoice restart the payment clock?
Usually yes, which is the expensive part. A rejection discovered three weeks late often means the payment terms effectively start again from the resubmission.
.avif)