Can AI sort our shared orders@ or ap@ inbox before anyone reads it?

Sorting a shared inbox doesn't mean reading it for someone. It is a short set of decisions made about every message before a person opens it, and each one can be checked against what your team actually did:

• What it is. On orders@: a new PO, a change or cancellation, a question about an open order, a quote request. On ap@: an invoice, a credit memo, a statement of open items, a past-due reminder, a W-9 or remittance question, a request to change payment details. On both, the newsletters, auto-replies and bounce messages that bury the rest.
• Who it is from. The customer or vendor account, which is often not the sender: a rep forwards a customer's PO, a property manager writes for an owner, a factoring company sends a supplier's invoices.
• How urgent it is. A ship-today order, a cutoff, a second notice, a credit hold. Urgency comes from your own rules, so it has to be written down before the test rather than guessed.
• Whether it repeats something. The same invoice sent twice, a PO resent with "please confirm", or one message copied to two addresses.
• What is inside. Which attachment is the document, which are logos and signatures, and which message in a forwarded chain is the one that matters.

Email's own standards explain much of the difficulty. RFC 5322, the IETF's Internet Message Format (2008), says that when a user forwards a message, it does not appear to come from the original sender: it is an entirely new message from the forwarder. So when a rep forwards a customer's PO to orders@, the From line names the rep. The customer, the original date and often the real subject sit further down, in text the sort has to read.

MIME, the standards that let one email carry several parts, adds layers. RFC 2046 (1996) defines a part that holds a whole encapsulated message, which is how many mail programs forward as an attachment, and a multipart/alternative body whose parts are versions of the same information, usually plain text and HTML. RFC 2183 (1997) separates parts displayed inline from attachments kept apart from the body. So a signature logo can arrive as an attachment, a PO as a message inside a message, and the same text twice.

Long reply chains are the last trap. A vendor answering a dispute may quote three old invoices above the new one it attached. Put those chains in the test on purpose, because a sort that reads the first invoice number it meets will file the message against the wrong one.

RFC 5322 also says every message should carry a Message-ID, a globally unique identifier, and that replies should carry In-Reply-To and References fields naming what they answer. That settles one kind of duplicate: a message delivered to both orders@ and a rep keeps one Message-ID, so the two copies can be matched. It does nothing for the other kind. A customer who resends a PO, or a vendor whose billing system sends the invoice again marked as a reminder, creates a new message with a new identifier.

Those repeats have to be caught on the document itself: the same PO number, the same invoice number and amount, the same lines in a renamed file. A sort should say "possible repeat of the invoice received on the 4th" and leave the decision to a person. It should never delete or hide one, because a resend is sometimes the corrected copy.

For a document job we ask for 20 to 30 finished documents. Sorting is judged across the whole mix, so the sample here is one exported month of the inbox instead, redacted and sent only after an NDA is signed. Nothing logs in to the mailbox, no rule is created in it, and no message is moved, answered or deleted. Pick an ordinary month with its usual mess: the heavy Mondays, the month-end statements, the out-of-office replies.

The answer key is what really happened to each message: which folder or queue it went to, who handled it, and what it became, whether an order, a posted invoice, a reply or nothing at all. Part of that lives in the mailbox and part in your ERP or AP records, so your reviewer, the person on your team who knows this inbox best, builds the key from both. Messages nobody handled belong in the key too; a sort that flags one is telling you something.

Check the export before it leaves. RFC 4155, which registers the mbox format, says the format has no authoritative specification and its separator lines vary widely between programs. Open a few messages from the file and confirm the attachments and the forwarded originals came with them. The federal rule for agencies' email records, 36 CFR 1236.22, makes a good checklist even where it doesn't bind: keep the sender, every addressee and the date, keep attachments that are part of the record, and keep the real names behind a distribution list, which is often exactly what orders@ is.

Your reviewer then compares each label with the key, message by message, against success criteria agreed before the test: which mistakes matter (a PO filed as a question), which don't (a newsletter filed as junk), and which would end it.

An inbox month carries more than the job needs. Before the export leaves, take out or redact:

• Mail that isn't the desk's work. Personal messages, HR and payroll threads, anything from counsel, and mail about the people on the team.
• Login links, password resets and one-time codes, which pile up in any shared inbox that signs in to customer or supplier portals.
• Bank and card details, swapped for consistent stand-ins rather than deleted. If a vendor's account changes mid-month, Account A becoming Account B in the copy lets the test see that a change was asked for without any real number in it.
• Mail a customer or vendor sent under its own confidentiality terms, until its owner agrees.

An ap@ inbox is where payment fraud arrives. The FBI's Internet Crime Complaint Center describes business email compromise as a scam aimed at the people who make legitimate funds transfers, often run from a real account taken over by social engineering or intrusion. Its 2023 notice adds that it isn't always about a transfer: some versions ask for employees' personal details or W-2 forms. FinCEN's 2016 advisory on email fraud, written for banks, describes a criminal posing as a supplier to say future invoice payments should go to a new account, and lists warning signs a sort can mark:

• An address that closely resembles a known one, altered by adding, changing or deleting a character.
• Payment to a known payee with account details different from the ones used before.
• Wording, timing or amounts unlike the sender's earlier, verified instructions.
• A request marked urgent, secret or confidential, or sent so there is little time to confirm it.

FinCEN also says no single red flag necessarily means fraud, and some reflect ordinary business. So the sort only flags: it names the signal, quotes the line that raised it and hands the message to a person, who checks it through the controls you already use. It never updates a vendor record, never replies to the sender and never declares a message safe.

Email authentication has limits worth knowing. The 2023 phishing guidance from CISA, the NSA, the FBI and the Multi-State ISAC tells organizations to enable DMARC, which with SPF and DKIM verifies the server that sent a message against the rules its domain publishes. A look-alike domain can pass those checks, because the mail really does come from the look-alike, so a passing result never makes a payment change safe.

FinCEN's 2019 update lists email auto-forwarding and inbox sweep or sorting rules set up in a victim's account among the technical signs of email compromise, one more reason the test creates no rule in your mailbox. If money has already gone, the IC3's advice is that time is of the essence: ask your bank to recall the funds and file a complaint at ic3.gov. None of this is legal or security advice; your IT team and counsel decide what may leave the building.