Book each night's Brex card spend into QuickBooks Online

Every night at 11pm, book the day's Brex corporate card spend into QuickBooks Online and post a recap to my finance channel in Slack. Use a cron trigger, since Brex does not push these to us.

Start by pulling card activity from Brex with List primary card transactions. Only take transactions that have settled since the last successful run: keep a watermark of the last run timestamp in the workflow's own state and use it as the lower bound, and on the very first run look back 24 hours. Page through the results with the returned cursor until there are no more.

Brex returns money as integer minor units plus a currency code, so an amount of 4250 with currency USD means 42.50. Convert to a decimal amount before writing anything to QuickBooks. If a transaction is in a currency other than the QuickBooks company's home currency, do not convert it yourself, send it to review instead.

Never book the same Brex transaction twice. Keep a persistent list of Brex transaction ids that have already been booked and check every candidate against it before doing anything else. Also stamp the Brex transaction id into the private note of every purchase you create, formatted as brex_txn:<id>, so a human can trace any entry back to the card charge. QuickBooks has no reliable way to search purchases by that note, so the workflow's own record is the source of truth for deduplication, not a re-query.

For each transaction, work out which merchant the raw card descriptor actually refers to. Descriptors are messy: they carry store numbers, city and state codes, processor prefixes like SQ * or TST*, and truncated names. Clean the descriptor into a likely merchant name, then look for an existing vendor in QuickBooks using Query Entities against the Vendor entity, matching on display name, and pull the full record with Read Vendor when you need to confirm the details. QuickBooks query only supports a trailing % wildcard and AND conjunctions, so search on a prefix of the cleaned name rather than a substring, and widen or shorten the prefix if the first attempt returns nothing.

You decide when a match is good enough to book. If exactly one vendor is a clear match, use it. If nothing plausible exists and the merchant name is unambiguous, create the vendor with Create Vendor using the cleaned name. If two or more vendors are plausible, or the descriptor is too garbled to name a merchant with confidence, do not guess and do not create a vendor: leave the transaction for a human and record the reason. Route to review rather than booking any refund or credit with a negative amount, and any charge above the review threshold the finance team sets.

Book each confident transaction with Create Purchase as a credit card purchase, paid from the QuickBooks account that represents the Brex card. Set the transaction date to the settlement date, the entity to the matched or newly created vendor, the line amount to the converted decimal, and the line's expense account to the one that fits the merchant category Brex reports. Read the chart of accounts once per run with Query Entities against the Account entity so you are only choosing from accounts that exist. If no expense account clearly fits the category, send the transaction to review rather than dumping it into a catch-all.

Finish with one Slack message to the finance channel using Send a Message. Give it three sections. Booked: merchant, amount, expense account, and vendor for each entry, plus a run total. New vendors: any vendor created during this run. Needs review: each skipped transaction with its raw descriptor, amount, and the specific reason it was skipped. If there was nothing to book, post a single line saying so, so a silent night is never ambiguous. Use Slack mrkdwn formatting, with *bold* section headers rather than double asterisks.

If Brex or QuickBooks fails partway through, stop booking, make sure the watermark and the booked-id list reflect exactly what was written, and say so in the Slack message so the next run resumes cleanly instead of double-posting.