Key takeaways
Key takeaways

Key takeaways

What this agent does

A coffee shop processes between four hundred and two thousand Square transactions a day. A barber shop processes between thirty and eighty. A food truck does about one hundred and fifty. None of those operators want to categorise each receipt by hand, and none of them want to pay a bookkeeper to do it either. The standard fix is a Square-to-accounting integration that batches every transaction as "Sales" and a separate batch as "Fees". That works until the operator is asked to file a tax return and discovers they cannot tell the difference between a coffee sale and a retail bean sale, or between a tax-included tip and a service charge.

The agent fixes that. Every night at 2 a.m. local time the agent pulls the previous business day's transactions from Square, runs each through a categorisation rubric tied to your chart of accounts, and writes one journal entry per category per location to your accounting system. The bookkeeper opens the books in the morning, sees a clean ledger, and spends their hour on the few transactions the agent flagged for review.

What the agent does not do: edit transactions in Square, refund customers, change Square item categories, modify the chart of accounts in the accounting system, send messages to customers, or generate financial statements. The single write surface is the journal entry endpoint. Everything else is a read. This is the same principle laid out in how an agent reconciles QuickBooks bank feeds.

Sources of truth

Square plus the accounting system. Two sources.

The agent does not read bank feeds, payroll, or customer data. The decision is intentional. Adding more sources turns categorisation into reconciliation, and reconciliation is a different agent. Keeping the two separate keeps both small. The same separation is argued in how to give an agent multiple tools.

The chart of accounts is the rubric

The rubric is not invented by the agent. It is the accountant's chart of accounts plus a mapping table. The mapping says, for example: items in the Square category "Brewed Coffee" go to revenue account 4010 (Beverage Sales, Coffee). Items in the Square category "Whole Bean" go to revenue account 4030 (Retail, Whole Bean). The Square processing fee goes to expense account 5210 (Merchant Fees). The Square hardware lease line item goes to expense account 5310 (Equipment).

The mapping is written once at setup, usually in about an hour with the accountant on the call. The agent reads the mapping at the start of each run. New items added in Square that do not have a mapping route to a holding category called Uncategorised, which the agent flags for human review. The agent never invents a mapping. If a new product launches that does not fit any existing account, the accountant decides whether to use an existing one or create a new one, and the rubric is updated explicitly.

Output: one journal entry per category, nightly

The nightly output is a small number of journal entries, not a flood. For a single-location coffee shop the daily output looks roughly like:

For a multi-location operator the same structure repeats per location, tagged with the location's tracking category. The whole nightly output for a five-location group is about thirty journal lines. It posts in a single API call as one batched entry per location and balances to the cent. If it does not balance, the agent halts and pings a human; it does not post a partial entry.

This is a deliberate departure from per-transaction posting. Per-transaction journal entries are accurate to the cent but make the ledger unreadable. The audit trail back to individual receipts is preserved in a tracking file the agent stores per night, open the journal entry, click the memo link, get the list of underlying transactions. For the broader rationale on this design, see agent audit trails.

Guardrails

Three guardrails are mandatory.

The agent does not touch payroll, customer profiles, or Square's loyalty program. It does not issue refunds. It does not write to bank feeds. The smallest possible write surface keeps the audit story simple and keeps the operator's accountant comfortable signing the books.

Common mistakes

Posting per transaction. The first version did this. The accountant called and asked for it to stop. Per-transaction posting makes the ledger unreadable and slows down the accounting system's reporting. One entry per category per location per day is the right grain.

Letting the agent create chart of accounts. The accountant has rules about how the chart is structured. The agent does not know those rules. Adding "AI agent created a new account" to the audit trail is something every operator hates. Always keep account creation human.

Treating tips as revenue. Tips are a pass-through liability in most jurisdictions. Categorising them as revenue causes a tax problem. The agent always uses a separate Tips Payable account by default and the rubric makes that explicit.

Skipping the twelve-hour delay. Real-time posting sounds modern and is a problem. A customer who pays at 5 p.m. and refunds at 6 p.m. shows as two journal entries instead of one. The delay collapses both into a single net entry and saves about ten percent of journal lines per day.

Forgetting per-location overrides. A two-location operator where one location is a bakery and the other is a cafe will see the same Square item names with different cost-of-goods accounts. The rubric must have per-location overrides. If the operator is single-location today and plans a second, the override scaffolding is worth setting up early, adding it later is a chart-of-accounts cleanup project. The principle is in how to update an agent when the process changes.

Frequently asked questions

Can an AI agent categorise Square transactions for bookkeeping?

Yes. The agent pulls every Square transaction from the prior business day, classifies each into your chart of accounts, and writes one consolidated journal entry per category to your accounting system. It does not edit Square. It does not invent categories. It only posts journal entries that map to accounts you already use.

Which accounting systems does this work with?

QuickBooks Online, Xero, and Wave through their public APIs. FreshBooks and Zoho Books work through the same mapping but require an extra OAuth step. The agent writes journal entries through the standard accounting integration endpoints. It does not touch invoices, customers, or items in those systems.

How does the agent handle tips, refunds, and partial captures?

Tips go to a separate Tips Payable account by default. Refunds reverse the original category split if the original payment is found, otherwise they post to a Refunds clearing account a human reviews weekly. Partial captures map to the same category as the original auth, with the unutilised amount on a Pre-auth clearing account that drains automatically when Square releases the hold.

Does the agent handle multiple locations?

Yes. Each Square location is mapped to a tracking category, department, or class in your accounting system depending on what the system supports. The categorisation rubric can have per-location overrides, for example, the bakery location's category for flour purchases is different from the cafe location's category for syrups.

What if the agent miscategorises a transaction?

When you correct a category in the accounting system, the agent reads the correction during its next run and updates the rubric for the item or merchant that triggered the miscategorisation. The journal entry stays. Corrections accumulate and the agent's accuracy on your specific transaction mix climbs past ninety-five percent inside the first month.

Three takeaways before you close this tab

  1. One entry per category per location per day. Not one per transaction.
  2. The chart of accounts is the rubric. The agent never invents accounts.
  3. Tips, refunds, partial captures all have their own clearing accounts. Edge cases are explicit, not hidden.

Sources