Accounts and jobs in step: a two-way QuickBooks and monday.com sync
Three Make scenarios from a larger two-way sync. Bills flow from QuickBooks Online to monday.com through a change-data-capture cursor; expense edits made on monday flow back to QuickBooks line by line; and an hourly reconciler refreshes the expense board in batches of fifty without touching what monday owns.
Where this applies
Contractors and project businesses that keep their accounts in QuickBooks Online and run jobs, costs and purchasing on monday.com.
- records per batched write
- 50
- bill-sync runs, 13–21 Oct, no errors
- 647
- between reconciliation passes
- 1 h
The problem
A contractor's office lives in the accounting system and its project managers live on the job boards. Both need the same bills and expenses: accounts to pay and report, project managers to see what each job has cost. Keying them twice is slow, and the copies drift the day someone edits one side.
Watch triggers look like the answer and aren't. They can miss a change or see the same change twice, and they know nothing about an expense split across three jobs. A sync trusted for job costing has to be exact about which changes it has seen and which fields each side owns.
What we built
A cursor, not a trigger
The bill sync keeps the time of its last read in a data store and asks QuickBooks' change-data-capture query for everything changed since. It moves the cursor forward, fetches the changed bills and looks each one up on monday, so a change is neither missed between runs nor read twice.
Create or update, in one write
An array aggregator collects the lookups, a router separates creates from updates, and a text aggregator builds one GraphQL mutation for the batch. Many bills cost one write to monday rather than one each.
Edits flow back line by line
When the field team edits an expense on monday (amount, job, category or receipt), a webhook-triggered scenario of about forty-five modules updates the matching purchase in QuickBooks. A router by expense type and nested routers rebuild its lines, including an expense split across several jobs, and an error route handles a rejected update.
An hourly reconciler that knows its place
A separate scenario makes one QuickBooks query for the whole window, slices the results into chunks of fifty without querying again, finds the existing monday rows for each chunk, and refreshes only the fields QuickBooks owns, in one batched mutation per chunk. Rows split across projects get a narrower refresh that leaves category and customer alone. It never creates rows: creation belongs to the sync.
A guard for duplicates
If the reconciler finds two monday rows carrying the same QuickBooks id, it raises an alert instead of guessing which one to update.
The outcome
The bill sync ran 647 times between 13 and 21 October 2026 without an error.
The reconciler ran 542 times between 18 September and 21 October: 531 successful runs and 11 errors.
The expense write-back runs on every edit; its run count was not part of the History read for this page.
Where it stops
These are three scenarios of a larger sync: invoices, customers, vendors, purchase-order numbers and attachments are synced by other scenarios that are not described here. The reconciler covers expenses only. A duplicate id raises an alert and waits for a person to resolve it. Eleven reconciler runs failed in the period read, and the failed runs were not opened.
Built with
- Make.com
- QuickBooks Online
- monday.com
- GraphQL API
- HTTP API
- Make data store
Patterns used
- Change-data-capture cursor
- Batched GraphQL mutations
- Field ownership rules
- Duplicate guard
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no