What Each Export Contains and How Rows Are Ordered

Every transaction carries a statement page number and an in-statement sequence — two fields that
would let you reproduce exactly the order transactions appear on the original statement. Those
fields exist, but no export applies them by default. An unsorted export returns rows in whatever
order the database happens to produce them, which is not guaranteed to match statement order.

If you need statement order — for example, you're building a tracing analysis that depends on the
sequence being exactly what the bank recorded — you have to sort explicitly:

1. Export to Excel.
2. Sort by account, then by statement page number, then by sequence.

That three-column sort reproduces statement order. The fields are there; the step just isn't
automatic.

"Matched" covers several distinct match types, and only one of them — a check-image match — links to
a check-item record at all. Even then, whether detail appears in an export depends on two
independent gates:

• Match type. Only a check-image match creates a link to a check-item record. Internal-transfer
  matches and bank-to-GL matches never populate check-item columns, even though they're described as
  "matched" in other parts of the product. If you're comparing an export with what you see on the
  Transfer Match or Cash Match screens and detail is missing, this is why — the transaction is
  matched for one purpose, just not to a check item.
• Confirmation status. Most export types (specifically, Bank Transactions and Matched Item Details, Excel and Bank Transactions and Matched ERP/Items Details, Excel) only show detail for
  fully confirmed check items — status Matched, not To Approve. A suggested pairing that hasn't
  been confirmed yet won't show detail in these exports. The exception is Bank Transactions and All Item Details, Excel, which includes items in any state.

If matched rows are exporting blank where you expect check detail, check which export type you used
and whether those items are actually confirmed. If the transaction is matched to something other
than a check item, no export will show check detail — that's structurally correct, not missing data.

On the Check Image Match screen, every item is labeled Front, Deposit Slip, Withdrawal Slip,
and so on. In an export, the same items are relabeled based on their role in the match:

• A check front sitting as a child beneath a matched deposit slip exports as Incoming Check.
• The same kind of front standing on its own as a matched item exports as Outgoing Check.
• An aggregate row exports as Item Total.

These labels are computed while the export is being generated, not read from a stored field, so
they're not editable and they're not visible anywhere in the interface. If you're comparing an
export against the platform and concluding the two disagree because the vocabulary is different,
that's exactly what's happening — in this respect they genuinely use different words for the same
thing. This is not a data error; it's a labeling layer applied at export time.

If you've run AI categorization or set custom labels and some transactions still export with blank
category columns, that's usually because categorization and exports are independent systems:

• AI categorization (the V8 default columns) and custom categories both run as separate background
  jobs. A blank cell means that job hasn't run on that transaction yet — or was never triggered at
  all — not that the export dropped something.
• A newly created custom category won't back-fill transactions you've already categorized by hand
  unless you explicitly run a re-categorization pass.

If blank categories are showing up in meaningful volume, check whether the categorization job
actually ran and whether the transactions in question were in scope for it. The export itself
doesn't drop data; it only reports what's in the database at the time you requested it.

If you see rows with Transaction Kind Item and an amount of zero, those are synthetic rows
representing one check within a matched deposit slip. The parent deposit row carries the real
amount; the Item row is there to preserve the check's own detail (payee, check number, date) as a
separate line. This is not a duplicate or an error — it's how multi-check deposits are structured
when expanded.