Skip to content

Vendor-invoice transactions render the wrong display name (missing invoice number, dangling separator)

Symptom

On the Bank Transactions table, a vendor-invoice-matched transaction's display name renders with the merchant only and a dangling | (no invoice number). Reported by the owner, 2026-06-21 (verbatim):

"a) Why is it that the display name for Vendor invoice didn't work on 8DX0qDUm5UuePIMVaPoK"

Observed name on the affected tx: [6010 - Telecommunications] Birdie | (trailing separator, empty invoice number). Expected (per the vendor_invoice doc-type template [{{accountCode}} - {{accountName}}] {{merchantCategory}} | {{merchant}} // {{invoiceNumber}}): [6010 - Telecommunications] {merchantCategory} | Birdie // 1447641076.

Source

  • Tx: 8DX0qDUm5UuePIMVaPoK
  • Match data on the tx (gl.6010): {payee: "Birdie", merchant: "Birdie", invoiceNumber: "1447641076", matchedFingerprint: "BIRDIE"} + receiptIds: ["nnTHOFq6acmdpI2S6q7l"]
  • Doc-type template (live in accounting/settings/docTypes/vendor_invoice): correct as shown above
  • Site: lib/accounting/transactions.ts β†’ enrichTransactionDisplayName β†’ linkedRecordType resolution chain (the V1 display-name path)

Diagnosis

The linkedRecordType chain has no vendor_invoice branch. A vendor-matched tx resolves to linkedRecordType = null because: - it's not a WOPC, not linkedBilling.type === 'workspace', not linkedBilling.type === 'gcp'; - matchedReceipts is empty (the V1 adapter derives matchedReceipts from gl.receipts, but the vendor link writes receiptIds + gl.{code}, not gl.receipts), so the receipt branch misses; - it's not GL 6400 cross-border.

With linkedRecordType = null, the vendor_invoice doc-type template is never fetched. The code falls through to GL 6010's own displayNameTemplate ([{{accountCode}} - {{accountName}}] {{merchant}} | {{gcpInvoiceNumber}}) β€” which references the GCP-only {{gcpInvoiceNumber}} token, so the invoice number renders blank and the | is left dangling.

Escalation β€” T-090 (the structural fix)

Escalated 2026-06-21 to T-090. The fix adds a vendor_invoice branch to the linkedRecordType chain, keyed on expenseMetadata.matchedFingerprint (the vendor matcher's signature, written by applyVendorLink), placed before the generic receipt check. vendor_invoice is already in the DocType union + token whitelist (payee, merchant, merchantCategory, invoiceNumber, …), so the existing template renders correctly with tokens already on the tx β€” no template change needed.

This ticket subsumes the part of I-001 that overlaps with vendor-invoice transactions specifically; I-001 stays open as the generic "display name renders wrong" symptom queue for any remaining variants.

2026-07-01 β€” fixed (via T-090)

Resolved via T-090 (done) β€” vendor-invoice display-name fix shipped on main. [owner: close I-003] - Source (edit): EOP Local Assistance (fork) Β· session edb0abc7-6373-449b-8e31-379fd38d391b