Requesting a corrected invoice

Some invoices cannot be coded as they arrived. The tax does not add up to the total, the property is wrong, the invoice number is missing, or two buildings are on one page when your agreement says one bill each. The fix is not an edit on your side — it is a corrected copy from the vendor.

inletAP will ask them for you, and the point of doing it here rather than from your own mail client is where the answer lands. The email carries a reply address on your own intake mailbox, tagged for this one request, so the vendor's reply and whatever they attach come back into this workspace and are tied to the invoice you asked about. You do not have to find it in an inbox afterwards.

Before you start

• The invoice must have arrived by email. The reply address is built from the intake mailbox the message came in on, so an uploaded invoice has none and the request is refused with that sentence.
• You need an address the vendor reads. The box is pre-filled from the address the invoice arrived from, which is very often a no-reply. Have the real one ready.
• Any internal member can send one. Admin, Controller Approver and AP Specialist all can, with no extra permission on top of reading the invoice: the person who finds a total wrong is whoever is looking at it. A Viewer — the outside approver role — cannot. What you may ask about is limited the way everything else is, by the properties you are scoped to. See roles and permissions.
• The invoice must not be exported yet. Once a bill is in your ledger the remedy is a credit note, and the button is not offered. Nor is it offered on a quarantined document, because nothing on a security hold is mailed to anyone.

1. Open the invoice and press Request info

Open the document from Inbox or Review Queue. Request info is in the action bar at the bottom of the screen, beside Save and Mark duplicate. On a phone it is in the More actions menu, under the same name.

The button is missing on an exported, partly exported or quarantined invoice. It is disabled, with the reason in its tooltip, when this invoice already has an open request — one at a time, so the thread stays readable. A message that was set aside as not an invoice gets a different screen altogether and has no such button; restore it first if it turns out to be a bill.

2. Check the address

The Send to box is pre-filled from the address the invoice arrived from, and it is yours to correct. That is the most important field in the dialog. An invoice from billing-bot@vendor.com or a statement run out of an accounting system will be delivered to a mailbox nobody reads, and a question sent there is a question asked of nobody.

An address belonging to somebody in your own workspace is refused. A forwarded or uploaded invoice carries a colleague's address rather than the vendor's, and mailing them "please send a corrected invoice" and then waiting is a failure with no error message at all. Type the vendor's own address instead.

An address we have stopped mailing fails later, not here. If it bounced or reported our mail as spam in the past, the form accepts it and the send does not happen. You are told after pressing Send — see step 4.

3. Say what you need

The note is optional and holds up to 1,000 characters. The box counts them for you.

Write the specific thing. The vendor gets your words quoted and set apart from ours, so "the tax on this invoice does not match the total, please send a corrected copy" reaches them as a sentence from a person. A note is not required, and a request without one still identifies the invoice and asks for a corrected copy.

This is what leaves the building:

• A subject naming your workspace and the invoice number, or "one of your invoices" when the document states no number.
• One sentence saying who is asking — your name, when your account carries one, and your workspace.
• The invoice, identified well enough for a stranger to find it in their own system: their trading name as you hold it, the invoice number, the amount and the invoice date. Each row is included only when it is known; nothing is invented to fill the block.
• Your note, quoted.
• The instruction, in its own paragraph: reply to this email with the corrected invoice attached. The reply address is printed in the body as well, because Reply-To is invisible to a person and some mail programs answer the From address instead.
• A footer saying a person at your workspace sent this through inletAP, and that there is nothing to unsubscribe from.

There is no link to the app anywhere in it. A vendor cannot open an invoice in your workspace, and a link that lands on a sign-in page reads as phishing.

4. Send it, and read what comes back

Press Send request. The message you get is about the mail, not about the record, and the difference is the whole reason this page can be trusted:

A request nobody was asked is recorded as undeliverable rather than open, and the banner on the invoice says so in those words. That matters more than it sounds: "waiting on the vendor" printed over a message sitting in nobody's inbox is the one failure this feature exists to remove, and it frees the invoice for another attempt at a different address straight away.

5. While you wait

Nothing about the invoice changes. It keeps the status it had, it stays where it was in the queue, and asking does not hold it back from approval or from export. A request is a question, not a workflow state.

What you see on the invoice is a banner: Info requested, the address, the date, and "Waiting for their reply". It carries a Cancel request button.

Cancel it when the vendor answered by phone, the address was wrong, or the invoice turned out to be fine. Cancelling tells the vendor nothing — it withdraws your own claim to be waiting, and it stops a later reply on that address being linked to this invoice. It is also how you free the invoice up to ask again, since only one request may be open at a time.

6. When the reply arrives

The vendor presses Reply. The message comes back to your intake mailbox on the tagged address, and three things follow.

It is not set aside as "not an invoice". The not-an-invoice gate stands down for a reply on an address we minted. A vendor who answers "what exactly is wrong with it?" with no attachment carries no invoice wording at all and would otherwise be filtered, leaving you waiting for a reply that had already arrived.

It becomes its own document, and the original tells you where. A reply with an attachment is read like any other invoice, so the corrected copy is a new row in the Inbox with its own extraction and its own confidence. It is not an edit of the invoice you asked about. The banner on the original changes to Vendor replied, with a link reading "Open the invoice they sent". When more than one reply came in, the banner says how many and the link takes you to the newest one that produced a document — because a real thread is often an acknowledgement first and the corrected invoice hours later.

The correction raises no duplicate card against the invoice it replaces. It would otherwise raise a loud one: a vendor who fixes a PO number and presses Reply sends the same amount, the same invoice number and often the same bytes. The duplicate rules hold that pair back by name, on the ground that you asked for this document and never received it before. The exemption covers exactly that one pair. The correction is still compared against every other bill in the workspace, because billing twice through a correction thread is precisely what those rules exist to find. See duplicate detection.

The link keeps working for further replies until you cancel the request or the address expires, which is 60 days after you sent it. After that a reply is still delivered and read — it arrives as an ordinary invoice, with nothing tying it to the original.

What you should be looking at

The original invoice, in the status it was already in, with a banner across it that says either "Info requested … waiting for their reply" or "Vendor replied" with a link to the corrected copy. Nothing has moved, and nothing was edited on your behalf.

Check it worked

The banner is the quick answer. The Audit Log is the one that holds up six months later, because all three events are recorded against the invoice you asked about:

• info_requested — who asked, the address, whether the mail actually left, the reason when it did not, and whether there was a note. Your note itself is deliberately not copied into the trail; it is already on the request, and spreading free text you wrote about a supplier adds no fact.
• info_request_cancelled — who withdrew it.
• vendor_replied — recorded against the original invoice, with the reply and the documents it produced. The actor is the system, not you: the vendor's mail server did this.

Filter the log to the invoice's record id and you have the exchange in order. If info_requested says the mail did not leave, the vendor never saw a thing, whatever the date on the row.

Limits worth knowing

• One open request per invoice. Cancel the open one before sending another.
• Five requests per invoice, ever. By the fifth unanswered email the vendor is not going to answer this way, and a sixth from software they never signed up to is what turns a supplier into a spam complaint — which then suppresses that address for every other invoice you hold.
• Sixty days. After that the reply address stops matching and a reply is filed as an ordinary invoice.
• Emailed invoices only. An upload has no mailbox to reply to.
• Not after export. Ask for a credit note instead.
• A suppressed address is never overridden. The one party in the exchange who told us to stop mailing them is the vendor, and we do not make an exception because your side of the conversation started it.

Where to go next

• Extraction problems — when the document is right and the reading of it is wrong, which needs an edit rather than an email.
• Duplicate detection — what happens to the pair the correction makes.
• Audit trail — the three events above, and how to get them out.
• Invoice statuses — the statuses that refuse a request, and why.