Who this is for. AP Helpdesk Analysts, Specialists and Managers, and ProcureToPay Managers and Agents. Every AP role can open this screen; the behavior it describes needs the AP Helpdesk function on the agent. See the Roles and Access.
The agent does not just sort mail. For every incoming message it classifies what the sender wanted, looks the vendor up, pulls their records, decides whether it can answer, and where it can, writes the reply. All of that work is on screen, and it is on screen whether the agent succeeded or not.
This article covers the three places that work appears, in the order you meet them: the Intelligent Summary at the top of the message, the Processing Timeline in the middle, and AI Reasoning and Related Info at the foot. Read them when you disagree with the agent, when a message stopped and you need to know where, or when a vendor asks you to justify a reply they were sent.
All three appear in the By Incoming Messages view. Switch to it before you start.
The Intelligent Summary
The first card in the reading pane is the agent’s reading of the message, so you can decide whether to read the message itself.
Figure 1. The Intelligent Summary, expanded with Show more.
Table 1. Parts of the Intelligent Summary.
Part |
What it holds |
|---|---|
EMAIL CATEGORY |
What the agent decided the message was, as a chip. The agent's later steps depend on this category. |
Description |
One sentence on what the sender wanted. |
KEY REQUESTS |
What the sender is asking for, as a list. Where there is more than one, the agent has to satisfy all of them before it can close the message. |
KEY INFORMATION |
Facts the agent pulled out of the message, such as an attachment name or an invoice number. Hidden until you select Show more. |
Show more and Show less |
Expands and collapses the card. |
Show AI Pipeline |
Takes you to AI Reasoning and Related Info at the foot of the message. |
If the category is wrong, stop reading here. Everything below it inherits the mistake, and the fix is in Override a Triage Decision.
The review task on a message
Under the summary sits a task reference such as AP-01176 (New), followed by an assignee. The reference is a link, and it opens the task itself.
A task appears here whenever the agent stopped and asked for a person. The status in brackets is the task status, and it is the same value the Task Status filter uses in the other view. The assignee defaults to Unassigned, and setting it is how a message stops being everybody’s problem.
The processing timeline
Below the message body and its attachments, Processing Timeline shows how long the agent took and where the time went. The heading carries the stage count, and the chevron collapses it.
Figure 2. The Processing Timeline.
Table 2. The summary cards.
Card |
What it reports |
|---|---|
TOTAL DURATION |
End to end, from arrival to the last stage finishing. |
STAGES |
How many stages ran, child stages included. |
BOTTLENECK |
The slowest single stage, and how long it took. |
FAILED |
How many stages failed. 0 reads all clear. |
PARALLEL |
How many stages ran at the same time. |
Under the cards, a legend colours the stages by the kind of work they do: Ingest, Precheck, IntelliSummary, Actions and Reprocessing, with Failed and Completed marking outcome.
The flow beneath it names each stage in order with its own duration, so a message that took far longer than usual can be traced to the stage responsible. The stages you will see on a typical message are pre-enrollment, sender resolution, email category, record fetching, rule evaluation and draft.
Use this when a message is late rather than wrong. A stage that never completed is the reason, and the Processing State filter set to Stalled finds the rest of them.
AI Reasoning and Related Info
The last section of the message is the agent’s working. It opens as a row of five stages, in the order the agent ran them, each with its own state: a tick where the stage completed, and its step number where you are looking at it.
Selecting a stage shows what happened in it. A stage the agent never reached, such as Submission on a message with nothing to submit, is still selectable and still tells you why it did not run.
Triage
The first stage records what the agent decided to do with the message and how sure it was.
Figure 3. The Triage stage.
Table 3. What Triage reports.
Part |
What it holds |
|---|---|
Chips |
The classification and the action, such as business and needs-review. |
Confidence |
How sure the agent was, as a bar and a percentage. A low figure on a message that was answered automatically is worth a look. |
Reasoning |
Why, in prose, and specific: it names the terms and the rules that decided the outcome. |
Override Controls |
Where you change the decision. See Override a Triage Decision. |
Correction History |
Every change already made, with a count beside the heading. Each entry names what changed, from what to what, why, and who did it. Changes the agent made itself are attributed to system. |
Correction History is the first thing to read when the agent’s behavior surprises you, because it distinguishes a decision the agent made from a decision that was later changed.
Email category detection
The second stage shows the categories the agent detected, each with its own confidence and its own explanation.
Figure 4. The Email Category Detection stage.
A message can carry more than one category, and each is scored separately. The explanation is worth reading when the score is low, because it usually names the one weak signal the agent relied on.
Manage Email Categories leads to the category configuration. That changes the agent’s behavior for every message, not this one, so treat it as a configuration change rather than a correction.
SOR
The third stage is what the agent found in your system of record once it knew who the sender was. This is the evidence behind any figure the agent quoted back to a vendor.
Figure 5. The SOR stage, with the matched vendor and the records pulled for it.
Table 4. What SOR reports.
Part |
What it holds |
|---|---|
Vendor |
The vendor the sender was matched to, with its identifier. |
Extracted Values |
Identifiers the agent found in the message body, such as an invoice or purchase order number, with a count. Where it found none it says so, and that is often why a reply was thinner than expected. |
Invoices |
The vendor’s invoices, with a count, listing invoice number, internal ID, amount, date and status. |
Payments |
Payments, with payment ID, amount, date and method. |
Purchase Orders |
Purchase orders for the vendor. |
Each section collapses, and the counts are on the headings, so you can tell at a glance whether the agent had anything to work with. A vendor with no invoices and an empty Extracted Values list explains almost every unhelpful reply.
Submission
The fourth stage handles documents that need to go into your system of record, and it is the one stage on this panel where you can act rather than read.
Figure 6. The Submission stage.
The table lists each attachment with the classification the agent gave it, the reference and amount it read off the document, and its confidence. Tick the attachments you want and select Transfer Selected. The banner above the table names the system they will be transferred into, and the line below it counts what you have selected.
An attachment classified unsupported carries no reference and no amount, because the agent could not read it as a document it handles. Transferring it is still possible, but nothing will be extracted from it.
Draft response
The last stage is the reply the agent wrote, exactly as it stands.
Figure 7. The Draft Response stage.
It shows the recipient, the subject, and the draft itself, with the same translation controls the message carries so you can read a draft written in another language. Where the agent quoted records, they appear in the draft as a table.
Read this before releasing anything. The draft is the only part of the agent’s work the vendor will ever see, and checking it against the SOR stage is the quickest way to confirm the figures in it are real.