QuickBooks and CodeWords: automating the bookkeeping around the ledger
Reconciliation, invoice chasing, expense capture, and the hard rule that nothing writes to the ledger without a person having decided it should.
Rebecca Pearson11 min read
On this page
Bookkeeping automation deserves a different default from everything else. In most systems, a mistake is inconvenient and reversible. In a ledger, a mistake is a correcting entry, an explanation to your accountant, and occasionally a conversation with a tax authority.
So the useful framing here is not what can be automated but what should be prepared and what should be posted. Almost everything worth building around QuickBooks prepares work for a person to approve, and the value is in the preparation rather than in removing the approval.
What we'll cover
- Prepare against post
- What the QuickBooks API reaches
- Connecting it to CodeWords
- Eight automations worth building
- Invoice chasing that does not annoy customers
- Building it so it survives
- Limits worth knowing about
- What to build first
- Frequently asked questions
Prepare against post
The distinction that should govern every decision here.
Preparing means assembling, matching, calculating, and presenting — a draft invoice with the lines filled in, a reconciliation showing which transactions match and which do not, a chase email written and waiting. A person reviews and commits.
Posting means writing to the ledger: creating the invoice, recording the payment, categorising the expense. This changes your books.
Automation is unambiguously good at preparing and should be approached carefully for posting. The reason is not that software makes more mistakes than people; it is that a person notices when something looks odd and an automation does exactly what it was told at whatever scale you gave it.
Where posting is automated, it should be for transactions that are high-volume, low-variance, and independently verifiable — a payment received matching an invoice exactly, for instance. Anything requiring judgement about which account, which tax treatment, or which period should be prepared and approved.
What the QuickBooks API reaches
Customers, vendors, and items can be read and written, which is the reference data everything else points at.
Invoices, bills, and estimates can be created, read, updated, and voided, including line items and tax detail.
Payments can be recorded and applied against invoices, which is the core of the reconciliation pattern.
Expenses and purchases can be created and categorised, with attachments.
Accounts and the chart of accounts can be read, which any automation posting anything needs in order to point at the right one.
Reports can be run through the API, returning the same figures the interface shows, which is how you get numbers out without exporting by hand.
Attachments can be linked to transactions, which is how a receipt stays with the expense it documents.
Webhooks notify on entity changes, which lets an automation react to something a person did in QuickBooks.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder, being explicit about what it should prepare and what, if anything, it may post.
- Authorize the connection through QuickBooks OAuth, against a sandbox company first.
- Describe the exceptions carefully: an amount that does not match, a customer who does not exist, a transaction that appears to be a duplicate.
- Run it against a sandbox with realistic data, and reconcile its output by hand before trusting it once.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Eight automations worth building
Payment reconciliation. Match incoming payments from your bank feed or payment processor against open invoices, apply the confident matches, and present the rest as a short list with suggested matches. The exceptions are where the value is, because those are the ones that currently take an afternoon.
Invoice preparation from another system. Draft invoices assembled from your CRM, your project tracker, or your usage data, with lines filled in and ready for review. This removes the retyping without removing the check.
Overdue chasing. Identify overdue invoices, prepare the chase, and send on a schedule you set. The next section covers doing this without damaging relationships.
Expense capture. Receipts arriving by email or upload, read, categorised with a suggested account, and attached to a draft expense for approval. Categorisation is exactly the kind of judgement a model does well and should not do unsupervised.
Reconciliation checks. Compare QuickBooks against your payment processor, your store, and your bank, and report the differences. Most bookkeeping problems are discovered here rather than in the ledger itself.
Recurring transaction verification. Confirm that the things that should happen monthly actually did: the subscriptions, the rent, the standing invoices. Absence is the failure nobody alerts on.
Management reporting. Run the reports you look at anyway and deliver them where people are, with the comparison against last period included rather than left for someone to work out.
Anomaly flagging. Transactions outside normal ranges, duplicate-looking entries, and expenses against unusual accounts, surfaced weekly for a look.
Invoice chasing that does not annoy customers
The automation people most want, and the one most likely to damage something.
Check whether the invoice is actually unpaid. Payment may have arrived and not been applied yet. A chase for an invoice the customer paid last Tuesday is worse than no chase at all, and it is the most common failure here.
Escalate in tone, slowly. A gentle reminder a few days after the due date, a firmer one after a fortnight, a personal message from a human after that. Automating the first two and stopping there is the right shape for most businesses.
Exclude accounts with something in progress. A customer disputing an invoice, or in a payment conversation with someone on your team, should not receive an automated chase. This needs the automation to check somewhere other than QuickBooks, which is exactly why it is worth building outside it.
Make the reply go to a person. A chase that arrives from a no-reply address tells the customer you do not want a conversation, when a conversation is usually how it gets paid.
Cap the sequence. After a defined number of attempts, hand it to a person rather than continuing indefinitely. Automations that chase forever are how a recoverable relationship becomes a written-off debt.
Never automate anything with a legal character. Final demands and anything mentioning consequences should be written and sent by a person who has decided to send them.
Building it so it survives
Make it safe to run twice. Creating an invoice twice is a real problem in a ledger. Check for an existing document with the same reference before writing, always.
Treat an ambiguous match as a rejection. A payment that could apply to either of two invoices should go to the exception list, not to whichever one sorted first.
Log every posted transaction with its reasoning. When an accountant asks why something was categorised a particular way, the log is the answer. This is not optional for anything touching the ledger.
Use the sandbox properly. QuickBooks provides one. There is no good reason for the first run of a ledger automation to be against real books.
Keep a human summary. A daily line stating what was prepared, what was posted, and what needs attention. If an automation posts to your ledger and nobody reads a summary of what it did, you have a bookkeeper nobody supervises.
Limits worth knowing about
Rate limits apply per realm, so bulk operations need pacing. Batch endpoints exist and are worth using.
Sandbox and production are different companies with different data and credentials, which is the point, and it means a test that passed proves the logic rather than the data.
Closed periods reject writes. An automation attempting to post into a closed month will fail, which is the system working correctly. Handle it as a business case rather than an error.
Tax handling is jurisdictional and detailed. An automation creating invoices with tax needs the treatment specified rather than inferred, and this is the area where a small mistake compounds quietly across many transactions.
Multi-currency adds a layer. Exchange rates, realized gains, and the date used for conversion are all decisions. If you trade in more than one currency, settle these explicitly before automating anything that posts.
What to build first
Reconciliation checks, running read-only. Compare QuickBooks against your payment processor and report the differences. It needs no write access, it almost always finds something on the first run, and it teaches you the data shape before you build anything that writes.
Two habits make the difference. Run it alongside whatever happens now for a cycle and compare, since the disagreements are usually genuine discoveries about your data. And have it report that it ran even when it found nothing, because a silent check cannot be distinguished from a broken one.
Frequently asked questions
Should an automation post directly to the ledger?
Only for transactions that are high-volume, low-variance, and independently verifiable, such as a payment matching an invoice exactly. Anything requiring judgement about account, tax treatment, or period should be prepared for approval. The approval is cheap and the correcting entry is not.
Can it categorise expenses automatically?
It can suggest categories well, and suggesting is the right mode. Categorisation affects your accounts and your tax position, so the useful arrangement is a draft with a suggested account and a confidence indicator, reviewed in a batch rather than one at a time.
How do I avoid duplicate invoices?
Check for an existing document with the same external reference before creating, and give every invoice a reference derived from the source system rather than generated fresh. This is the single most important guard in any accounting automation, because webhooks retry and people click twice.
What happens if it tries to write into a closed period?
QuickBooks rejects it, correctly. Handle that as an expected business case — route the transaction to a person to decide where it belongs — rather than treating it as a technical error to retry.
Is it safe to connect QuickBooks to other systems?
With scoped permissions and a clear view of what writes where, yes, and the reconciliation automations are read-only. Be deliberate about which system is authoritative for what, because two systems both believing they own customer records produces a mess that takes longer to untangle than it took to build.
How should I test this?
In the sandbox company QuickBooks provides, with data resembling yours, and then by reconciling the output by hand for a full cycle. Accounting is the domain where running in parallel before switching over is least negotiable.
Can it handle multi-currency?
Yes, and only if you specify the treatment: which rate, from what date, and how gains are recorded. These are accounting decisions rather than technical ones, and an automation that infers them will be consistently wrong in a way nobody notices for months.
How do I handle partial payments?
Explicitly, because they are common and the default behaviour is rarely what you want. Decide whether a payment smaller than the invoice should be applied partially, held for review, or flagged, and specify it. An automation that applies partial payments silently produces invoices that look paid and are not.
What should the daily summary contain?
What was prepared, what was posted, what needs attention, and what failed. If an automation touches your ledger and nobody reads a summary of what it did, you have a bookkeeper nobody supervises, which is exactly the arrangement an auditor will ask about.
What should never touch the ledger automatically?
Anything involving judgement about which account, which tax treatment, or which period. Those three decide how your accounts read and how much tax you pay, and an automation making them consistently wrong is far harder to unwind than one that prepared them for review.