What it can't do

This software writes to a firm’s books. You should know what it can’t undo before you point it at a client file, not after. Most of what follows comes from the QuickBooks SDK rather than a decision anyone made here. Where there’s a workaround, it’s named.

​

A plan is not a dry run

qb_plan_batch validates against your file’s real chart of accounts, name lists, and existing transactions. It catches most of what QuickBooks would reject. It can’t catch everything. A closed-period password, an unusual company preference, or a permission on your QuickBooks user account surfaces when the entry actually posts. That happens per entry, with the rest of the batch unaffected, and the failure comes back with QuickBooks’ own message.

​

Transfers are a one-way door

Three separate SDK gaps land on the same transaction type. No idempotency key. TransferAdd accepts none. Every other transaction type carries a key derived from its content, so re-applying an interrupted batch skips what already posted. Transfers have only the run journal, and the run journal only knows about postings this software made. Can’t be voided. qb_reverse_run voids everything else a run posted. Transfers are reported back for you to handle by hand. Can’t be deleted either. TxnDelType has no Transfer value — only TransferInventory — so deleting one fails with an enum error. Removing a posted transfer means opening the account register in QuickBooks and deleting it there.

​

Cleared status is not reconciliation

qb_set_cleared_status sets the cleared flag on a transaction. That’s all it does. qbXML has no request that creates a reconciliation record with a statement date and an ending balance. Finishing a reconciliation means opening the Reconcile window in QuickBooks. Transfers can’t be addressed this way at all — QuickBooks rejects them.

​

There’s no way to attach documents

QuickBooks Desktop’s Attached Documents feature has no SDK surface. None — this was verified against the full qbXML 16.0 message set, not assumed. Keep source documents in your own system. Give every entry a sourceRef — an invoice number, a bank feed id, a filename — and the run journal links each posting back to the document it came from. qb_explain_transaction reads that link back to you later.

​

One caller at a time

The QuickBooks request processor is single-threaded and serves one company file. Every tool call goes through a single queue, and a batch holds one session for its whole run. Registering a practice’s clients doesn’t change this. Registration names files; it doesn’t make them simultaneously reachable, and a call naming a file QuickBooks doesn’t have open fails before anything happens. See several company files. Questions asked against the local copy are the exception: those span every client at once. Two programs driving QuickBooks at once collide. If this workstation also runs Zenofirm’s QuickBooks connection, see running alongside the QuickBooks sync.

​

Duplicate detection needs a source reference

Two transactions with identical dates, amounts, and coding are indistinguishable, and preflight blocks the second one as a duplicate. If they’re genuinely separate — two $450 utility payments on the same day — give each a distinct sourceRef. That’s what tells the software they’re different, and it’s what makes the block go away.

​

It only knows what it posted

The run journal records every write this software makes. It doesn’t know about anything typed directly into QuickBooks, imported by another tool, or posted before it was installed. Planning does check your company file for near-identical transactions someone entered by hand, over the date range the batch covers. That check is advisory and costs one query per transaction type.

​

An unlicensed install has 250 postings

An install without a licence key may post 250 transactions in total, for the life of that workstation, in batches of any size. That’s an evaluation allowance, not a per-run cap: it doesn’t reset, and splitting the work into smaller batches doesn’t buy more. An evaluation gets every feature, including the ones only Enterprise includes. The allowance is the only limit, and it limits volume rather than capability — an evaluation is where you find out whether this fits. A posting counts when a transaction is created, changed, voided or deleted and QuickBooks accepts it. What doesn’t count:

• Anything that fails, is blocked at preflight, or is skipped as a duplicate. You’re only charged for work that landed.
• Anything that isn’t a transaction — adding a customer, a vendor, an account, a class, an item, a payment term.
• Reversing a run this software posted. qb_reverse_run is always free, so undoing a mistake never costs you anything.
• Reads, reports, plans, reviews, the run journal, coding rules, and the local copy. None of those are limited in any state.

If a batch would take you past what’s left, it’s refused whole, before anything posts — a run never stops halfway because an allowance ran out. qb_plan_batch says so while you’re still deciding whether to approve it, and qb_status shows the count at any time. Earlier versions capped an unlicensed batch at 10 entries per run instead. That limit is gone, and so is the advice to work around it by planning twice.

​

A licence covers builds, not time

A licence key is perpetual, but it covers builds, not time: every build released during its update window is covered permanently. The check compares the key against the build’s release date, never against today’s date, so the version you have keeps working forever. Installing a build released after your update window closed is the one thing that changes the answer. After 14 days of grace, that build limits batches to 10 entries per run — and gets no lifetime allowance, because you own the software, you just don’t own that build. Renew updates, or reinstall a version your key covers, and it’s back to normal. A key can name one workstation per seat. On a machine the key doesn’t name, the install runs with the evaluation allowance and tells you the machine’s id so support can move a seat to it. A key issued without any binding runs anywhere. No licence state ever refuses reads, reports, planning, review, or reversal. Those are unconditional.

​

A licence covers a shape of work

There are three licences — Core, Practice and Enterprise — and what separates them is the shape of the work rather than how much of it you may do. Cross-company questions, shared practice state, and the inventory domain are the three differences; everything else, including the whole safety apparatus, is identical in all three. There is no meter on a paid licence. The 250-posting allowance above exists to limit unpaid work; a meter on work you have paid for would make a bookkeeper batch less, which would undo the review loop this software is built around. Two things a licence never rations, at any price: your own books, and the ability to undo what this software did. See Core, Practice and Enterprise for what each covers and what a refusal looks like when one doesn’t. qb_status reports your tier and what it covers under license.tier, and the Setup Center’s Licence tab says the same thing in a sentence.

​

It only runs on the workstation

QuickBooks Desktop exposes an in-process, 32-bit COM server. There’s no network protocol to reach it with, so this software runs on the same computer as QuickBooks, as a 32-bit process. Reaching QuickBooks from another machine is possible in principle — it takes a proxy on the QuickBooks machine that accepts connections and forwards them to the COM API. Some tools ship one. We don’t, and won’t by default: it turns a company file into a network service, with full write access to a client’s books behind whatever authentication the proxy happened to implement. If a firm needs that arrangement, use a remote desktop session to the machine that already has the file. So: no hosted version, no server deployment, and one workstation per company file.