Automated finance reporting: Stripe, WeTravel, QuickBooks in a single source of truth

In the ecommerce and service-led projects I work on, the same scene plays out almost every morning. The finance team opens the day with three or four tabs: Stripe, a secondary booking or checkout platform, the accounting system, and a Google Sheet they hand-filled the night before. From those tabs a report is born that is supposed to be “the source of truth”, but is already out of date by mid-morning and contains a few duplicates nobody had time to chase down. The cost is not just hours: it is a margin nobody can read with the precision needed to make pricing or product-mix decisions.

This article describes a pattern I have used several times to consolidate revenue from multiple streams into a single source of truth — Stripe, a booking platform like WeTravel, and accounting exports from QuickBooks or Xero — using Make.com as glue. The goal is not “automate the final report”. It is to eliminate the manual reconciliation work and produce numbers the accounting team can sign off without reopening sources.

The real problem is not export, it is dedup

Anyone who has tried to aggregate Stripe with another processor or with a booking platform knows the hard part is not pulling data. Both ecosystems offer APIs or CSV exports. The hard part is that the same payment often shows up twice: a Stripe transaction matching a booking handled elsewhere, or a payment that originates on a third platform and lands as a settlement in the bank account the accounting system tracks.

Without a robust dedup key, end-of-month revenue inflates by 15-25%. With a wrong key, it inflates anyway but invisibly. The first real piece of work, before writing a single Make scenario, is defining the right composite key.

In an education/travel project I worked on, that key turned out to be Program + Email: the program slug the customer enrolled in, plus their lowercased email. Neither Stripe nor WeTravel alone carried enough information to dedup — they had to be crossed. The pipeline:

1. Daily Stripe payment retrieval via CSV export (or API in cleaner cases).
2. Daily WeTravel booking retrieval via API.
3. Normalization: trim, lowercase email, match program name against an alias table.
4. Build the composite key slug(program) + "|" + lower(email).
5. Upsert into a “master finance” Google Sheet using that key as unique identifier.

The practical result is that the same payment, even if it appears in both sources, ends up as one row in the master. From that row you can break revenue out by stream (programs, retreats, products, and so on) and produce per-category dashboards without ever double-counting.

The QuickBooks “no custom reports” workaround

QuickBooks Online is a solid accounting system but it has a well-known limit: its API does not expose the custom reports you build in the UI. You can however extract standard reports — P&L, Balance Sheet, Aged Receivables, Aged Payables — via the /reports endpoint, and build everything else downstream from there.

The pattern I use is straightforward: a scheduled Make scenario (daily for summarized P&L, weekly for full balance sheet) that hits the QBO endpoint, parses the hierarchical JSON response, and writes structured rows into a sheet. From there, pivots and charts become a Sheets problem, not a QuickBooks problem. It is a workaround, not an elegant solution, but it eliminates the manual rework the finance team does every Monday.

For teams on Xero instead of QuickBooks the pattern shifts but the principle holds. In a luxury furniture resale project I handled the entire flow with a “Xero Daily Journal Sweep”: a nightly cron (pg_cron on Supabase in that case, but the pattern is identical in Make) that at 02:00 collects the day’s transactions, builds journal entries, and posts them to Xero through a dedicated dispatcher. Every write — invoices, journals, edits to already-issued invoices, gift card carve-out handling — goes through the same dispatcher. Business logic lives in one place; Xero becomes the sink, not the system in charge.

Architecture in practice

The typical multi-source architecture with Make.com is three-layer:

Ingestion layer. One scenario per source, each on its own cadence. Stripe every four hours, WeTravel every four hours, QuickBooks once a day post-close. Each scenario writes to a denormalized staging sheet, preserving original fields.

Normalization layer. One scenario running overnight: reads staging sheets, applies normalization rules (program alias map, lowercase email, currency conversion at daily rate), builds dedup keys.

Master layer. A single “truth” sheet, with upsert by key. Pivots, Looker Studio dashboards, accountant exports all flow from here.

Separating the three layers means that when a source changes format — Stripe renames a field, WeTravel introduces a new booking type — you only touch ingestion. Normalization rules stay centralized, and the master knows nothing about sources.

The realistic metric

On a project with two main revenue streams and medium volumes (a few hundred transactions a month), manual consolidation and reconciliation took roughly two hours a day: download CSVs, dedupe by hand, build pivots in Excel, check totals. After the pattern described above went live, residual work is about five minutes a day: open the master, check the “rows requiring attention” indicator (transactions that failed normalization and landed in a quarantine sheet), decide case by case.

Two hours to five minutes is a 24x factor, but it is not the number that matters most. The number that matters is that the accounting team signs off the month-end report on day one, not day five. Monthly close shifts from a week to a day. That in turn enables faster pricing and mix decisions, because the numbers management needs no longer arrive three weeks late.

When not to do this

This pattern does not make sense at very low volumes (under twenty transactions a month, doing it by hand is faster) or when a single source is already handled well by the accounting system. It also does not make sense if the priority is tax compliance in complex jurisdictions: that requires a chartered accountant with dedicated tools, not a Sheets consolidation. Make.com shines in the middle ground — a few hundred to a few thousand transactions a month, two or three streams to cross, a small finance team that wants time to think about numbers instead of copying them.

Automated finance consolidation is not glamorous. It is not the use case that makes slides sparkle. But it is probably the one with the most direct ROI and the easiest case to defend to a CFO: time recovered, errors eliminated, faster monthly close. Three numbers in the language the CFO already speaks.