Demo

Same agent.
Different knowledge.

One invoice, two finished runs. Same model, same tools, same SAP. Only the context changes.

Invoice processingSAP · Accounts payableSecond scenarioComing soonThird scenarioComing soon

An invoice arrives from a German vendor.

A US manufacturer's AP agent receives one PDF and has four moves to make: read it, extract it, match it to the purchase order, post it in SAP. Both runs below make all four.

Global Precision Parts GmbHIndustriestrasse 44, 60314 Frankfurt am Main, Germany
VAT ID: DE281734955
accounts.receivable@globalprecisionparts.de | +49 69 5550 1122
INVOICE
Invoice #: INV-EU-20394
Invoice Date: 20-Aug-2026
Due Date: 19-Sep-2026
PO Number: 4500128873

Bill To

Meridian Industrial Manufacturing Inc.
Accounts Payable Dept.
1450 Commerce Parkway
Cleveland, OH 44115, USA
Vendor No. (Buyer's ERP): 100234

Ship To

Meridian Industrial Mfg. — Plant 3
Receiving Dock B
780 Foundry Road
Cleveland, OH 44115, USA

DescriptionPO LineQtyUnit PriceAmount
Precision Ball Bearing — Type 6205-2RS10500 ea$4.85$2,425.00
Machined Steel Drive Shaft — 45mm x 300mm20150 ea$38.20$5,730.00
CNC Milled Housing Bracket — Alu 606130200 ea$12.60$2,520.00
Hex Socket Cap Screws M8x40 (box of 100)4040 box$18.90$756.00
Freight & Handling (EU export)1$310.00$310.00
Subtotal$11,741.00
VAT (0% — Intra-EU export, reverse charge)$0.00
Total Due$11,741.00

Remit-To Bank Details

Account Name: Global Precision Parts GmbH
Bank: Commerzbank AG, Frankfurt Branch
IBAN: DE89 3704 0044 0532 0130 00
BIC / SWIFT: COBADEFFXXX
Currency: USD (settled via EU correspondent account)

Global Precision Parts GmbH · Industriestrasse 44, 60314 Frankfurt am Main, Germany · Registered: Amtsgericht Frankfurt HRB 88213

One PDF. Two clauses that decide the run.

Everything either agent knows about this invoice starts here. Both read the header, the five lines and the total correctly. That was never the hard part.

The two highlighted fields are the ones this company's own rules attach to: the vendor contact, and the account the invoice settles through. Neither is an error. Neither is flagged. Neither changes the total.

An agent reading the document alone has no reason to treat either as special.

View source document
Without Trail

Works from the document alone.

Capable model, correct extraction, real SAP writes. Nothing about this run is broken.

With Trail

Works from the document and the context graph.

Same model, same tools. Before each move it checks what this company already knows about this vendor.

01 · Submit

Invoice arrives in the AP queue

document_retrieval · Vendor mailbox

INV-EU-20394.pdf lands from Global Precision Parts GmbH and is picked up for processing.

01 · Submit

Invoice arrives in the AP queue

document_retrieval · Vendor mailbox

Identical. Nothing has diverged yet.

02 · Extract

Read the invoice

agentic_data_extraction

Vendor, PO 4500128873, five line items, $11,741.00 total, zero VAT. Clean extraction.

02 · Extract

Read the invoice

agentic_data_extraction

Identical, down to the field. Extraction was never the difference.

03 · Match

Pull the SAP order on the PO number

sap_read · SAP

Finds order 4500128873. Quantities and totals line up against the goods receipt. Marks it matched and moves on.

03 · Match · diverges

Pull the SAP order, and the vendor master

sap_read · SAP ×2

Finds order 4500128873 and matches it. Then makes a second read the other agent had no reason to make: vendor master 100234, to check the invoice contact against the registered address on file. It matches, and the verification is attached to the match as evidence.

From the context graph

Vendor 100234 carries a contact-verification control: the invoice contact must be checked against the SAP vendor master before a match is accepted.

AP controls v3 §2 · vendor 100234
04 · Post

Post the invoice in SAP

sap_post · SAP

Creates the vendor invoice against the purchase order. No errors, no exceptions, nothing to escalate. Run complete.

04 · Post · diverges

Post the invoice, routed to the EU account

sap_post · SAP

Creates the same vendor invoice against the same purchase order, then writes the payment note onto it: settle through the EU correspondent account, per this vendor's remit terms. Treasury sees the routing before it pays, not after.

From the context graph

Global Precision Parts settles in USD through an EU correspondent account, not the default US house bank this company pays most vendors from.

Treasury routing v2 · vendor 100234

Posted. Two things quietly missing.

  • The contact-verification control on vendor 100234 never ran. Nothing failed, so nothing was flagged. There is no evidence for the audit.
  • No payment note. Treasury settles $11,741 from the default US house bank to a German IBAN. It returns days later as rework, after the discount window.

Status in SAP: posted · no exceptions raised

Posted, verified, and payable first time.

  • Invoice contact verified against vendor master 100234, with the check attached to the document as audit evidence.
  • Settlement routed to the EU correspondent account before the invoice ever reached treasury. Paid once, on terms.
Both moves cited to rules in the graph

Same agent. Same tools. Same SAP. The only difference is what it knew before it acted.

Model
Identical
Steps run
Four, both
Added lookups
Two, from the graph
Rework
None vs. one payment

Your vendors have rules like this. Trail already knows them.

Show us one process your agents get almost right, and we'll run it against your own context graph.

Illustrative run, built on a real invoice. Not live product data.