> ## Documentation Index
> Fetch the complete documentation index at: https://zenofirm.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# One journal for a whole team

> Give several bookkeepers one set of coding rules, one client knowledge base and one posting history

Zeno learns as you work: coding rules, notes about a client's books, playbooks, and a record of everything it has posted. By default all of that lives on the workstation that learned it, so a second bookkeeper starts from nothing and never sees what the first one already worked out.

Point every workstation at one folder on your server and they share it.

```powershell theme={null}
.\Install-QbMcp.ps1 -DataDirectory '\\fileserver\QuickBooks\Zeno'
```

Run the installer with the same `-DataDirectory` on each PC. That is the whole setup.

<Note>
  Working from a shared folder is included with the **Practice** licence — see [Core, Practice and Enterprise](/docs/quickbooks-desktop/plans#shared-practice-state). Reading one is never gated: on any licence, and with no licence at all, a workstation pointed at the share can open the console, read every run, plan, rule and note on it, and reverse a run. What Practice covers is *writing* through it.

  A workstation that is meant to work on its own points `-DataDirectory` back at its own PC and is unaffected.
</Note>

## What becomes shared

| Shared across the team                      | Stays on each PC                   |
| ------------------------------------------- | ---------------------------------- |
| Coding rules                                | Licence seat                       |
| Client knowledge and playbooks              | The console and its password       |
| The work log                                | Logs                               |
| Every run and what it posted                | The record of an interrupted write |
| Duplicate detection                         |                                    |
| Registered companies and their local copies |                                    |

Duplicate detection is the one worth pausing on. Zeno fingerprints everything it posts, and a shared journal means those fingerprints span the office — so a bill Ann entered on Tuesday comes back as **already posted** when Bob's batch includes it on Thursday, on a different PC.

Only one workstation needs to sync a client's [local copy](/docs/quickbooks-desktop/questions). Everyone queries what it built.

## Use the server's own name, not a drive letter

<Warning>
  Pass `\\fileserver\QuickBooks\Zeno`, not `Q:\Zeno`.
</Warning>

A mapped drive letter means something different on each PC, and nothing at all on one whose login script has not run yet. Register a client through `Q:` on one desk and `\\fileserver` on the next, and Zeno treats them as two different clients — two local copies, two sets of coding rules, and a practice-wide total that counts that client twice.

The same applies when you register a company file. Use the full `\\server\share` path.

`qb_doctor` checks this and names any registration still keyed by a drive letter. The fix is `qb_forget_company` then register again with the full path; nothing you have posted is affected, because the history is keyed by company name rather than by path.

## Setting up the folder

* Put it on the same server as the company files.
* Give every bookkeeper read and write access to it.
* Exclude it from on-access virus scanning, the same advice Intuit gives for the `.QBW` file itself.
* Register each client **once**, from one workstation. The others pick it up.

## Who did what

Everything anyone records is stamped with their Windows account and the machine they were sitting at — `ann@RECEPTION-PC`. That is what tells two bookkeepers apart in a history they both write to.

If you would rather see real names, set `Operator` in `appsettings.json`, or the `QBMCP_Operator` environment variable, on each workstation.

The review console fills in the reviewer's name for you rather than asking. If someone changes a decision a colleague already made on the same batch, the console says whose decision it replaced instead of quietly overwriting it.

## Two people, one batch

QuickBooks Desktop still works on one company file at a time, and Zeno still posts only to the file that workstation has visibly open. What a shared journal adds is arbitration between desks:

* **A batch is posted once.** A run claims the plan before anything reaches QuickBooks. If Bob applies a batch Ann is already applying, he is told which run has it and nothing is sent. A run that fails before posting anything hands the plan back.
* **A client's local copy is synced by one workstation at a time.** A second sync is refused, naming who started the first and when. If that workstation crashes, the lease frees itself after fifteen minutes.

## What each workstation still needs

QuickBooks Desktop must be installed on every PC that uses Zeno — the connection is in-process, not a network API, so there is no way to reach a copy of QuickBooks on the server. See [which connection](/docs/quickbooks-desktop/which-connection).

Each bookkeeper opens their own console at `127.0.0.1:8082` with their own password. It reads the shared journal, so everyone sees the whole team's work, but the console itself is never exposed on the network.

Licences are per workstation. A key can name several machines; `qb_doctor` prints this machine's id if you need a seat moved to it.

## Moving an existing install onto a share

Nothing migrates automatically, and there is no merge. Pick the workstation whose history you want to keep, copy its `%LOCALAPPDATA%\Zeno\qb-mcp` folder to the share, then reinstall each workstation with `-DataDirectory` pointing there.

Upgrade the workstations together. A journal written by a newer version of Zeno refuses to open in an older one rather than half-reading it, so a PC left behind will say so plainly and ask to be updated.