We built the accounting system we needed

We were spending about $7,000 a year to get our tax work done, and we still did not know what we owed until year end. Before anyone could prepare the return we had to collect receipts, close invoices, and reconcile data spread across Stripe, Square, our banks, credit cards, and payroll.

We needed one system that could:

• keep the receipt required for every GST/HST input tax credit;
• close invoices when the matching payment arrived;
• split Stripe and Square payouts into sales, taxes, tips, and fees;
• connect every bank and credit-card account;
• track tax paid through purchases and payroll;
• track HST collected, input tax credits, and HST remittances; and
• show the amount owing throughout the year.

We looked at building on QuickBooks first. API access requires an application and approval, and once you have it there is no reconciliation endpoint. You can read and write transactions but you cannot reconcile an account through the API, and reconciliation is the step that proves the books against a bank statement. That was the part we most needed to automate.

We also wanted the books to be transparent: every number traceable to the record behind it, and every change attributable to whoever made it.

A Square deposit is not revenue. It can include sales, HST, and tips, less processing fees. Equated records those parts separately and tracks the HST until it is remitted. Stripe payouts are handled the same way. Once that data was in one ledger we could see revenue recognition clearly and give accounting agents access through MCP.

Agents prepare the work and people approve changes to the books. We learned why the hard way: an agent matching three months of Shopify Ads receipts to card charges went one slot off on the first match and stayed off for ninety of them, and QuickBooks accepted every one. In Equated a person or an agent can propose a match, but nothing posts until someone confirms it. If there is no reliable match, the receipt stays unmatched.

Equated uses a standard double-entry ledger. Each posting records an account, the original currency and amount, the company's base-currency amount, and the exchange rate between them. Account balances are calculated from those postings instead of being stored separately.

The database checks that the original amount, exchange rate, and base amount agree to within one cent. Journal entries must balance to zero in the base currency.

Entries are draft, posted, or void. Drafts can be edited. Confirmation posts an entry. Posted entries are never rewritten; they can only be voided or corrected with another entry.

Posted entries cannot be edited in place. A correction creates a new entry, which keeps the original record intact.

To change a posted entry, a user first unposts it. Equated creates a draft correction linked to the original. If the user makes a change, Equated posts only the difference. The correction keeps the original entry's date, so reports update in the correct period.

The current value is the original entry plus all posted corrections. The database allows only one open draft correction for an entry at a time.

Agents connect through MCP. They can read the books and prepare work such as categorizing a charge, attaching a receipt, closing an invoice, or voiding an entry. They cannot post directly to the ledger.

Each proposed change shows the accounts, amounts, and exchange rate that will be used. A person confirms it before it posts. Equated keeps the request, the preview, the result, and the identity of the person who approved it.

Each preview includes the version of the records used to prepare it. If any record changes before confirmation, the preview is rejected as stale. Unused previews expire after one day.

Confirmed actions are also idempotent. Retrying the same action returns the first result instead of posting it twice. This makes normal agent retries safe.

Each integration has a cutover date. Stripe, Square, payroll, and other sources import records from that date forward because older activity is already included in the opening balances.

Bank feeds import all available history and apply the cutover when the data is read. That lets us move the cutover date without creating a gap in bank history.

For banks that aggregators do not support, Equated connects through a read-only API token or a browser sign-in. Both methods return the same account and transaction format. Browser profiles are isolated by company and login, so changing the login creates a new profile instead of reusing the previous person's session. Browser-based syncs sign in again on every run, and credentials are stored encrypted and decrypted in memory only for the sign-in step.

Some banks send every amount as positive and put the direction in a separate transaction type. We map every supported type explicitly. If the direction is unknown we stop the import rather than guess whether money came in or went out.

Declined, cancelled, and failed transactions are not imported. If a provider later removes a transaction, Equated deletes draft entries, voids posted entries, and leaves reconciled entries unchanged. The connection screen only lists institutions we can support.

A reconciliation covers one account through a statement date. It records the previous verified balance, activity since then, the new statement balance, and any difference. Reconciliations must be completed in order.

While it is open, Equated recalculates those amounts whenever the reconciliation is viewed. Late transactions are included automatically. The final values are saved when the reconciliation is completed.

Completion requires a statement balance, no unconfirmed transactions, and a zero difference. A user can explicitly accept a non-zero difference, and Equated records it as a discrepancy rather than a match.

Once an account is reconciled, earlier entries stay closed. No entry dated on or before the statement date can post to that account unless the reconciliation is reopened. Agent previews are checked against the same lock before a person confirms them.

This lock currently covers accounts backed by bank feeds. It is not yet a company-wide closed-period lock.

Each account is mapped to a line on the corporate tax return. Canadian companies can map accounts to more than 400 GIFI codes. US companies use Form 1120 line numbers. The API and reference documentation use the same catalog.

The same ledger also makes revenue recognition visible. Revenue, deferred revenue, invoices, and payments stay separate, so a cash deposit does not have to stand in for earned revenue.

A confirmed mapping takes priority over a default or a name-based suggestion. Built-in accounts start with confirmed mappings. An unmapped account can inherit from its parent category; if it still cannot be mapped, Equated asks the user.

Tax adjustments are applied in the return. Half of a meal expense is added back on Schedule 1, and fines are not deductible. The ledger also determines which tax questions are relevant, and questions that are not triggered stay available but are collapsed by default.

A return will not build if an account is unmapped, a required question is unanswered, a carry-forward balance is unused, or the totals do not reconcile to the ledger. Filing saves a fixed snapshot. Amendments are stored as new revisions instead of changing the filed return. Our tests rebuild a real 2024 return from its books, compare every line with the filed return, and verify that known accounting errors are rejected.

Equated currently runs alongside QuickBooks for Hyperspeed's books. QuickBooks stays in place until a full parallel year matches entry for entry.