The wire landed at 14:07.
You knew at 14:08.
Your bank, your invoices, your Slack.
Wise sends a webhook when a wire credits. BT forwards an SMS the moment it hits. Gmail catches what the bank emails. The matcher reads any of them, looks up the open invoice in your AR system, posts the answer to wherever your team reads.
Wise
Incoming-payment webhook (the fast path).
Banca Transilvania
SMS notification via Gmail forwarder.
Gmail
Notification surface for SMS and email alerts.
Zoho Books
AR system, open-invoice lookup.
Slack
Where the team reads.
Proof from the channel.
What lands in the HKR finance Slack every morning at 7:00: Septillion's overnight Zoho sync. Which customer invoices flipped to paid, which got sent, all in one post.
Live post · 1 May 2026 · #incoming-payments
A single wire, 14:07.
Eight questions a serious buyer asks.
The hourly cron interval bounds the worst case. In practice, the matcher fires the next cron tick after the notification lands — typically inside the same minute for Wise webhooks, inside two minutes for BT SMS. If you need sub-minute P99, the dispatcher moves from cron-poll to webhook-direct; the architecture supports both. The page shows the cron-poll numbers because that's what HKR runs.
Every Wise webhook carries a unique ID; we keep a seen-set in state. Every BT SMS keys off Gmail's message ID plus a wire fingerprint of amount + timestamp + sender. The AR-system post carries the wire fingerprint as an idempotency key, so a double-fire posts once or no-ops. When reconciliation reads the next-day statement, it sees wires already posted by surveillance, skips the post, and just confirms provenance.
Wise emails go to a person. The post in Slack goes to a channel matched against your open invoices — already labeled with which invoice closed, already posted to your AR system, already threaded with the audit trail. The notification isn't the work; the matching-and-posting is.
Whatever bank publishes a webhook, an SMS, or a push alert can plug into the same matcher. ACH-direct to a US bank: most modern US banks expose a notification API (Mercury, Brex Cash, JPM API for enterprise). Older regional banks without notifications fall back to the reconciliation cycle — the wire surfaces when the statement lands instead of when the wire lands.
Lane 3 escalation. Slack post in #sales-ops with the wire details and the closest three candidate customers (by name similarity, recent-invoice timing, amount range). The human resolves; the resolution writes the new customer to the AR system, after which the next wire from the same sender matches automatically.
Configurable. Default amount threshold is $500. Below that, the wire matches and posts silently — the audit trail catches it, Slack doesn't. Key-account allowlists override the threshold (any wire from a top-10 customer notifies regardless of amount). Channel routing splits priority customers into a dedicated channel. The defaults reflect what HKR actually runs.
Customer in EUR pays a USD invoice. The wire arrives in USD on the USD account; the conversion happened at Wise's rate upstream. Match against the USD invoice at the USD amount the wire arrived as. The FX gain or loss vs. the invoice's USD value at issue date posts to your FX gain/loss account automatically, escalates if the delta exceeds tolerance.
They handle different triggers. Surveillance fires on the bank notification — seconds after the wire lands but works wire-by-wire. Reconciliation fires on the statement — hours later but works batch-with-completeness. Surveillance answers 'did ACME pay?' the minute it happens; reconciliation answers 'did every wire on yesterday's statement land where it should?' the morning after. Most mature finance teams run both. They share the matcher; the cost is the second trigger pipeline.
See it run.
A 30-minute walkthrough on HKR's own surveillance runtime. The actual median latency. The dedup behavior. A wire walked end-to-end, land to Slack post.

