monday.com to Xero, QuickBooks or MYOB: six invoice automations we have built, and the hard part of each

There are four routes. monday.com's own QuickBooks integration, documented in its Help Center, syncs customers from monday to QuickBooks and brings invoice fields back: balance, document number, the shareable link and totals. monday CRM's Quotes & Invoices feature makes quote and invoice documents inside monday, with each line as a read-only subitem, but that is a document in your CRM, not an entry in your ledger. Zapier and Make connect monday.com, forms and CRMs to all three ledgers through steps you arrange, though for MYOB we found no native app on either, so that route runs through their HTTP or webhook steps against the MYOB API (our MYOB automation guide covers it). And each ledger has an API for anything the platforms cannot express. In monday's Help Center we found no native integration for Xero or MYOB, so for those two the choice is Zapier, Make, a third-party app or code.

Our position is that the record people already work in should decide when to bill, the ledger should hold what is owed, and the automation in between should do as little as possible: find the customer, build the lines, create the invoice once, write its ID back. Where that breaks: if your invoices are simple and you are on QuickBooks with monday CRM, the native integration may be all you need, and a build is a cost without a return. If the invoice is raised in the ledger by an accountant who never opens the board, there is nothing to automate on the monday side at all.

This article covers invoices that start in monday.com, a form or a CRM. Orders from an online shop are covered in our WooCommerce to Xero article, which also goes through line items on Zapier and Make in detail. What happens after the invoice exists (sending, reminders, payments and credit notes) is on our accounts receivable automation page.

Strip away the apps and every build below is the same six steps. The differences are in which step is hard.

1. 01Trigger: a status or tick on the record, a form submitted, a signup, or an email arriving.
2. 02Guard: stop if the record already carries an invoice ID.
3. 03Customer: find the ledger contact by a stored ID or email, and create it only if nothing matches.
4. 04Lines: one invoice line per thing being billed, each with its account or item and its tax code.
5. 05Create: as a draft for a person to check, or final if the source is trusted.
6. 06Write back: the invoice ID, number and status onto the record, and any failure to a person who will read it.

On monday.com there is one extra trap. An automation that updates the item that triggered it can trigger itself again, so write the invoice ID to a column the trigger does not watch. Our monday.com automations article covers the board side of that.

These come from our Upwork work history and our published Make write-ups. Clients are described by industry and country only. Where a job had no client review, we give the brief as the client wrote it and the design we would use, not a claim about the result.

1. A monday.com tick raises a MYOB invoice (Zapier, Australia)

• Trigger: a specific condition ticked on a monday.com item.
• Steps: the brief was a Zapier automation that creates a MYOB business invoice when that box is ticked, so the team stops re-keying invoices. In the shape we recommend, the Zap looks up the MYOB customer, picks the invoice layout, builds the lines, creates the invoice and writes the invoice number back to the item.
• The hard part: MYOB is strict about references. The invoice names its customer by MYOB's internal ID, not by name, so the customer must be found first. Each line needs a tax code by ID. The invoice layout is chosen by the endpoint you post to, and a Service invoice line points at an account, while an Item invoice line points at an inventory item. A checkbox is also the easiest trigger to fire twice: untick and re-tick it and you have a second invoice unless the item already stores the first one's number.
• Evidence: a two-week fixed-price contract in May and June 2026 for a business in Australia. No client review was left.

2. A monday.com billing status raises a Xero invoice (Make)

• Trigger: a student's billing status changing to the label for a recurring, enrolment or upfront fee.
• Steps: published in our Make write-up on CRM-triggered invoicing, for a vocational training provider. Each scenario finds the contact in Xero, creates an authorised invoice due in seven days with a line built from the CRM's price, item code and description and a revenue tracking category, sends it through Xero's own email, and writes Waiting Payment, the invoice number, the issue date and the link back onto the item. Three scheduled scenarios were built to chase unpaid invoices.
• The hard part: re-triggers and contacts. The write-up says so in its own words: “Creating an invoice is not idempotent: selecting the trigger label again raises a second one.” And: “The recurring scenario matches by name and has no fallback, so a contact it does not know is skipped.”
• Evidence, as Make's counters show it: “Across the six scenarios: 78 runs and 782 operations in Make's counters, with one error, a duplicate contact name in the create-contact step.” Its limits also say: “Nothing here writes 'Paid' or 'Overdue' back to the CRM, so something else must set those.” The three invoicing scenarios are live; the three reminders have run 14 times between them and are switched off.

3. A Kajabi signup creates a QuickBooks customer and invoice, and payment unlocks the course (Zapier)

• Trigger: a new signup in Kajabi, then a QuickBooks invoice being paid.
• Steps: the brief was two Zaps with documentation. The first creates a QuickBooks Online customer and an invoice when someone signs up in Kajabi. The second sends a welcome email and grants access to the Kajabi product once that invoice is paid.
• The hard part: tying the payment back to the person. The second Zap starts in QuickBooks, which knows a customer and an invoice, not a Kajabi member, so the first Zap has to leave a key that the second can follow: the QuickBooks invoice ID stored against the signup, or the signup's reference on the invoice. Without it, a customer who pays an older invoice, or pays part of one, can be given access to the wrong thing. QuickBooks also requires each customer's display name to be unique across customers, vendors and employees, so two students with the same name need a rule before the first one signs up.
• Evidence: a fixed-price contract in September and October 2025 for an online-course business. No client review was left.

4. Five Cognito Forms feed Xero (Zapier, South Africa)

• Trigger: a submission on any of five Cognito Forms.
• Steps: the brief was an integration that moves the details from five forms directly into Xero through Zaps.
• The hard part: five forms are five mappings onto one ledger. Each form names its fields differently, and all five have to land on the same contact and the same account and tax rules. The second difficulty is time: forms change. Someone adds a question or renames a choice, and a Zap that mapped the old field keeps running and writes the wrong value. A form also has no record to write an invoice ID back to, so the submission's own entry ID is the key to store and check.
• Evidence: a fixed-price contract in January 2025, followed by a 24-hour hourly contract that ran to March 2026, for a client in South Africa. That pattern of a build and then adjustments is what we would expect of form integrations. No client review was left.

5. SmartSuite enrolments become one draft Xero invoice per guardian (Make, Australia)

• Trigger: enrolments recorded in SmartSuite for a tutoring centre.
• Steps: the brief was draft Xero invoices built from those enrolments, one per guardian, with each enrolment as a line item.
• The hard part: grouping. The record that exists is the enrolment, but the payer is the guardian, and a guardian with two children in three classes should get one invoice with three lines, not three invoices. On Make that means collecting the enrolments, grouping them by guardian and building one line array per group before the Xero module runs. Drafts are the right choice here. Xero lets a draft hold incomplete lines, such as a missing account code, and a draft creates no journals, so a person can check a term's invoices before any of them reach the books.
• Evidence: a fixed-price contract in January 2025 for a tutoring centre in Australia. No client review was left.

6. Emailed bills go through an approval sheet into QuickBooks (Make, Zapier, Apps Script and OpenAI)

• Trigger: a supplier bill arriving by email.
• Steps: we built an accounts payable flow in which emailed bills are logged to a Google Sheet, approvers initial them, and the bills are posted to QuickBooks Online. Project names are extracted from each bill and fuzzy-matched against what is in QuickBooks. The stack was Make, Zapier, Google Sheets, Google Apps Script and the ChatGPT API.
• The hard part: the match. Project names on a supplier's bill are never typed the way they are in QuickBooks, so an exact match finds nothing and a loose one can find the wrong project. A wrong match is worse than none, because it posts cost to the wrong job. That is why the approval step comes before the posting: approvers initial each bill before anything reaches QuickBooks.
• Evidence: a 15-hour engagement from June to September 2025, with a 5-star final review and this mid-contract review: “Saveez is top notch. His work, communication and cooperation were all better than expected. I will absolutely continue to work with him.” — Upwork review (5★, mid-contract), QuickBooks accounts payable automation.

Pattern 6 is bills, not invoices, and it is here because the same three problems appear in reverse: matching a supplier instead of a customer, building lines with the right account, and never posting twice. Our accounts payable automation page covers the supplier side in full.

The same six steps meet three different sets of rules. This table is what each ledger's developer documentation says, as far as we could confirm it in October 2026. Where we could not confirm something, the cell says so.

Three rows matter most for a build from monday.com or a form. First, draft or final. In Xero you can create a draft and let a person authorise it, which is what the SmartSuite build did. In MYOB and, as far as we could find, QuickBooks Online, there is no draft invoice, so a build that should not hit the books yet has to create a sale order or an estimate and convert it later, or hold the record back until it is approved on the board. Second, safe retries. Only Xero and QuickBooks offer one, and neither lasts long enough to stop a re-trigger next week. Your own stored invoice ID is the guard in all three. Third, MYOB's references. Almost everything on a MYOB invoice is referred to by ID (customer, account, item, tax code), so a MYOB build does more lookups per invoice than the other two, and caching those IDs on the board saves both calls and errors.

Where the table breaks: these are the general-purpose APIs. Zapier's and Make's apps for each ledger expose some of these fields and hide others, and they change. Check what the action you plan to use actually offers, especially line items and tax, before you design around it.

Which event raises the invoice?

A status that means one thing (Ready to bill, Enrolment fee due) set deliberately by the person who knows the work is billable. Avoid a checkbox, which is easily untoggled, and avoid any column people edit for other reasons. On monday.com, give billing its own status column rather than reusing the delivery status, so a project moving back a stage cannot bill it again.

Draft or final?

Draft when a person should look first: grouped invoices, first runs, anything with judgement in the price. Final when the source is trusted and speed matters, as in the Make flow that authorises and emails the invoice in one pass. The cost of final is that a mistake is an authorised invoice to void, not a draft to delete. If you go final, start with drafts for the first few weeks and compare them with what you would have raised by hand.

One invoice per record, or per payer?

If one customer pays for several records (enrolments, jobs, deliveries in a month), decide whether they get one invoice or several before you build. Grouping changes the trigger from 'this record is ready' to 'this period is ready', which usually means a scheduled run, not an instant one.

Where does the duplicate check live?

On the source record: the ledger's invoice ID stored on the item, the form entry or the CRM record, and checked before every create. It is the rule our fleet order automation follows on monday.com for incoming orders, where a resent order corrects the existing row instead of creating another, and it applies to invoices just the same. Add the ledger's retry protection where it exists, but do not rely on it.

• Orders from WooCommerce or another shop into Xero, including line items, shipping, refunds and the off-the-shelf connector: our WooCommerce to Xero integration article.
• Everything after the invoice exists, including sending, reminders that check the balance first, payments and credit notes: our accounts receivable automation page.
• Supplier bills, approvals and the payment run: our accounts payable automation page.
• The board side, including action quotas and why recipes stop: our monday.com automations article.

Skofi is paid to build integrations on Zapier, Make and the ledger APIs, so we gain when you build. Our advice is still to try monday's native QuickBooks integration, or your ledger's own features, first. We are not a partner of monday.com, Xero, Intuit, MYOB, Zapier or Make. The builds above come from our Upwork work history, where as of 21 October 2026 we are Top Rated with a 100% Job Success Score over 114 jobs, and from the Make write-up named above.