01 · Context and stakes
Notch is a Toronto company that automates invoicing, payment collection and ordering for wholesale food and beverage distributors and the restaurants they supply. It started in 2015 as ChefHero, a marketplace for restaurant ordering. When COVID-19 closed dining rooms, it moved to the money side of the same relationship. It launched an accounts receivable (AR) product in July 2021 and an accounts payable (AP) product in January 2023.
That pivot changed what the software was responsible for. An ordering app that fails costs a restaurant an order. A payments platform that fails sends money to the wrong invoice or leaves a distributor's books out of step with their bank. Distributors keep those books in their own accounting and ERP systems, so the product is only as good as its integrations with them.
They engaged us in 2022 to help build those integrations: payments, OCR capture of invoices and documents, and two-way sync with accounting and ERP systems. OCR was the reason they came to us. Blackbird has built production OCR systems for years, and Notch needed invoice capture that holds up on real supplier documents, not a demo.
In July 2026 Telpay, the cash flow control platform for Canadian businesses, acquired Notch. Telpay's announcement says Notch's technology is now part of Telpay, and that over time it plans to bring invoicing, one-time payment collection and ordering into its platform. We stayed on as the team that maintains and develops the app.
02 · Constraints
- A live payments product. Distributors collect real money through it every day, so every release has to leave payments and sync working.
- Ledgers Notch doesn't control. Distributors use QuickBooks Online, QuickBooks Desktop, NetSuite, Microsoft Dynamics 365 or Xero, each with its own data model and its own API, and the vendors change those APIs on their own schedule.
- Card data and regulation. Card payments have to stay within PCI DSS scope.
- A change of owner mid-engagement. After the acquisition, the product had to keep running for its customers while the new owner worked out how it fits into Telpay.
03 · Architecture
The platform serves two sides. Distributors work in a web AR app and give their customers a payment portal. Restaurants order and pay in a web ordering and AP app and an iOS app. Both web apps are React and Redux, served from a Kubernetes production cluster on Google Cloud behind a TLS gateway. The backend is Java and Spring, with PostgreSQL as the database.
What we added since 2022:
- Payments. Card and EFT payments against open invoices, with card details collected by a PCI-compliant payment processor.
- Accounting and ERP sync. One-way or two-way sync of invoices, payments and customers, with automatic cash application that matches each payment to the invoices it pays. CSV batch upload covers any system without an integration. Our team worked on all five integrations: QuickBooks Online, QuickBooks Desktop, NetSuite, Microsoft Dynamics 365 and Xero.
- OCR capture. Supplier invoices arrive as PDFs or phone photos. The text is extracted, lines are coded to general-ledger accounts, and the result syncs to the ledger. We built the OCR engine ourselves on top of Google's cloud services, with a person in the loop. The engine extracts each invoice, suggests GL coding and scores its own confidence. High-confidence invoices sync automatically, which is about 90% of them; the rest go to a person to check before they sync.
The decisions below are the ones that shaped that work. In practice the integrations are more involved than any summary: each accounting platform behaves differently, and so does each business using it, with its own chart of accounts, tax setup and habits for credits and partial payments.
Distributors (AR)
Web
AR web app
Invoices, reminders, cash application
Customer payment portal
Where their customers pay
Down to Platform, via: HTTPS, TLS gateway
Platform
Java + Spring backend
PostgreSQL
Kubernetes on Google Cloud
Shared production cluster
Restaurants (ordering and AP)
Apps
Web ordering and AP app
iOS app
Down to Platform, via: HTTPS, TLS gateway
Platform
Java + Spring backend
PostgreSQL
Kubernetes on Google Cloud
Shared production cluster
Payments (our focus)
Payments
Card and EFT payments
Against open invoices
Down to Processor, via: Tokens and payment status only
Processor
Payment processorPCI DSS
Card details stay here
Invoice capture and sync (our focus)
Capture
Custom OCR engineHuman in the loop
On Google Cloud; suggests extraction and GL coding
Confidence routing
About 90% auto-processed; the rest checked by a person
Down to Sync.
Sync
Internal invoice and payment model
One adapter per ledger
One-way or two-way, cash application
Down to Ledgers, via: Vendor APIs, authorized by the distributor
Ledgers
QuickBooks Online
QuickBooks Desktop
NetSuite
Microsoft Dynamics 365
Xero
CSV uploadFallback
Who uses the platform, the services we built into it, and the systems it connects to. 04 · Decisions
One internal model for invoices and payments, one adapter per ledger
- Considered
- A third-party unified accounting API; ledger-specific code inside each feature; our own adapters behind one internal model.
- Chose
- Invoices, payments and customers live in one internal model. Each accounting system gets its own adapter that translates to and from it.
- Why
- QuickBooks Desktop, NetSuite and Xero disagree on what an invoice, a credit or a partial payment looks like. Each distributor also uses its ledger in its own way. Features like reminders and cash application shouldn't need to know any of that.
- Trade-off
- Five adapters to maintain as vendors change their APIs, per-customer configuration on top of each one, and an internal model that has to cover the strictest ledger.
Let each distributor choose the sync direction, with CSV as the floor
- Considered
- Two-way sync for everyone; one-way only; a per-distributor choice plus a CSV fallback.
- Chose
- One-way or two-way sync per distributor, and CSV batch upload for anything not integrated.
- Why
- Some finance teams want the ledger to stay the only place records are created. Others want Notch to write back. CSV means no distributor is blocked by a missing integration.
- Trade-off
- More sync modes to test, and CSV users don't get automatic cash application.
Automatic cash application only where the match is clear
- Considered
- Matching every payment by best guess; matching nothing automatically; matching clear cases and handing the rest to a person.
- Chose
- Payments that map unambiguously to open invoices are applied automatically. Partial, combined or unclear payments are left for the distributor's team to apply.
- Why
- A payment applied to the wrong invoice is worse than one waiting for review. It shows the customer as paid when they aren't, and it has to be unwound in the ledger.
- Trade-off
- Some payments still need a person, so the automation rate is lower than a best-guess matcher would report.
Auto-process by confidence, with a person on the rest
- Considered
- Posting every extracted invoice straight to the ledger; reviewing every invoice by hand; routing by confidence score.
- Chose
- OCR extracts the invoice, suggests GL coding and scores its confidence. High-confidence invoices sync automatically; the rest go to a person before they sync.
- Why
- Photos of paper invoices vary in quality, and a misread total that reaches the ledger costs more to fix than a short check before posting.
- Trade-off
- The confidence threshold has to be tuned and watched: set too low, misreads reach the ledger; set too high, people review invoices the engine already got right.
Keep card data with the processor
- Considered
- A direct gateway integration that brings card numbers into Notch's systems; a processor that collects card details itself.
- Chose
- Card details are collected by the payment processor and never reach Notch's servers. The platform works with tokens and payment status.
- Why
- It keeps PCI DSS scope small for a lean company, and card security stays with a specialist.
- Trade-off
- Processing fees and a dependency on one provider's API and pricing.
05 · Security
Card data with the processor
Card details go to the payment processor and are stored in line with PCI DSS. The platform handles tokens and payment status only.
Ledger access authorized by the distributor
Each accounting connection is granted by the distributor through the vendor's own authorization flow, and can be revoked from either side.
TLS at the edge
Traffic to both web apps terminates TLS at a gateway in front of the production cluster.
Secrets kept out of the code
Processor and accounting-vendor credentials are injected per environment, never stored in the repository.
Tested before release
Payment and sync changes are reviewed and tested before they reach production.
06 · Delivery
1. Joining in 2022. We joined a product that was already live, with AR launched the year before. The first work was learning the payment and invoice paths end to end before changing them, then building the payment integrations.
2. Integrations and OCR. We extended the sync layer across five accounting and ERP systems and built the invoice-capture flow. Integration changes are tested before release, because a sync error lands in a customer's books, not just in Notch's database.
3. Scaling the team. As the integration work grew, the team scaled to 5 developers, working within Notch's roadmap and priorities.
4. Through the acquisition. When Telpay acquired Notch in July 2026, we became the maintenance team. The product kept serving its customers on the same release path, run by the same engineers who built its integrations.
5. Today. We maintain the app and keep developing it: vendor API changes, fixes, and features for distributors and their customers.
07 · Results
Accounting and ERP integrations
live today
QuickBooks Online, QuickBooks Desktop, NetSuite, Microsoft Dynamics 365 and Xero, plus CSV upload
Supplier invoice entry
live today
About 90% of invoices processed automatically by confidence score; the rest checked by a person
Cash application
live today
Payments matched to open invoices automatically where the match is clear
Engineering team
2022 onward
Before: Engaged in 2022After: Scaled to 5 Blackbird developers
After the acquisition
since July 2026
Before: Product engineering for NotchAfter: Development and maintenance of the app under Telpay's ownership
- Payments, OCR invoice capture and accounting and ERP sync built into a live payments product.
- Our team scaled to 5 developers, working alongside Notch's in-house engineers.
- When Telpay acquired Notch in July 2026, we became the team maintaining and developing the app.
- An ongoing engagement, from 2022 to today.
08 · Team
Up to 5 Blackbird developers, working as one team with Notch's in-house engineers: their VP of Engineering and their own developers. Notch brought us in for our production OCR experience, and the engagement grew from there into payments and integrations. Notch's founders and leadership built the company, set the product direction and made the call to pivot into payments. Their VP of Engineering led engineering; we took on the payments, OCR and integration work inside it, and later the maintenance.
Who owned what: Notch owned the product, the roadmap, engineering leadership, payments compliance, and the relationships with customers, payment processors and accounting vendors. Alongside their engineers, we built and maintained the payment integrations, the OCR capture flow and the accounting and ERP sync. Since the acquisition we have owned development and maintenance of the app.
What we'd do differently
Not much. What we'd carry into any similar engagement: in a system this complex, working closely with the company's leadership is what keeps delivery smooth. Communication and working relationships matter as much as the code.