Owner's Manual for an AI bookkeeping app

The app is built as one bookkeeping product around a workspace. That workspace holds the people, settings, billing limits, and the same bookkeeping sections your team uses to handle statements, expenses, transactions, reports, contacts, chart of accounts, and the AI Bookkeeper. On mobile, the companion app uses the same workspace and adds Capture, Documents, AI Chat, and Settings. This chapter is based on the code we reviewed, so it tells you what the app does today, not what you may want it to mean, and it marks where document extraction or integrations may still sit outside this repository.

• Explain the app as one workspace-based bookkeeping product with web and mobile companion surfaces.
• Name the main workspace sections and understand why statements is the default starting point.
• Distinguish owner, workspace owner, admin, member, and viewer language without collapsing them into one role.
• Identify the main boundaries that the repository does and does not prove, especially around permissions, creation limits, and external processing.

The table below shows the split the reviewed shell actually establishes. Privileged roles share most access, members are narrower, and viewers are blocked.

This is the practical consequence of the shell design: the product does not treat role as a single yes-or-no state. It uses role to separate privileged bookkeeping control from ordinary participation, and then it uses account state as an additional check on creation. The boundary that stays visible here is important too: the shell tells you how the current checks behave, but it does not prove that every future settings path will keep the same split between local and server-side enforcement.

For the owner, the consequence is that a receipt photographed on mobile and a document uploaded elsewhere both enter the same bookkeeping flow. The app is not creating a second account model or a second processing path for those files. AI Chat stays inside the same workspace too, but it is gated differently. The client sends workspace and session information, the server checks membership, workspace state, and usage limits, and one chat credit is deducted before model work begins. If credit deduction fails, the stored user message is removed, so the request does not proceed as a free answer. That makes the chat experience workspace-scoped from the start and credit-aware before any model response is produced. The boundary remains local and specific: the reviewed evidence shows the gating and ordering around mobile ingestion and chat, but it does not describe the internals of extraction or the language model itself.

The table shows a shared workspace with different jobs on each surface. The web shell is the broader bookkeeping workspace, while mobile is the companion surface for capture and workspace-scoped chat. The evidence does not show two separate account models, and it does not suggest that switching workspaces on mobile happens anywhere except Settings when more than one workspace is available.

The settings surface is narrower than a generic profile page. The reviewed evidence only confirms writes for workspace name, currency, timezone, date format, and fiscal-year fields, and it confirms backend enforcement that only admins can apply those writes. The local settings experience may or may not add its own precheck; this review does not establish that part. What it does establish is the boundary itself: if a change is outside that field set, the evidence here does not prove that the product supports it.

The Xero integration shows a different kind of boundary. The visible card is disabled, but the server-side authorization and disconnect flows are still live and can change integration state. So the disabled card should not be read as proof that the integration no longer exists; it only means the visible UI is not the active control surface right now. For an owner, the consequence is that integration state can still move even when the screen looks inert.

The strongest thing about this foundation is that it reads as one product instead of several loosely connected parts. The web shell opens the workspace in statements by default, and the surrounding navigation keeps the main bookkeeping sections in one shared frame. That matters because the owner does not have to learn a different mental model for each surface or each task: the same workspace, the same bookkeeping terms, and the same starting point keep the product legible.

This coherence is not just cosmetic. It gives the owner a stable way to explain the product to a team, a bookkeeper, or a support person without constantly translating between screens. When the manual says statements, transactions, reports, contacts, chart of accounts, or AI Bookkeeper, it is describing parts of one bookkeeping system rather than separate modules with separate rules. The result is less room for confusion about where work belongs.

The other strong point is that the reviewed evidence does not hide the risky edges. It shows where role differences matter, where workspace creation is constrained, where membership control is explicit, where chat uses workspace credits, and where an integration can still exist as a server-side boundary even when the visible web surface is disabled. For an owner, that is more useful than a vague promise of control, because it tells you which actions are ordinary navigation and which ones change account state, permissions, or cost.

A simple example makes the value concrete. If a workspace owner asks why a member cannot do a particular action, the answer is not hand-wavy: some actions are blocked by role checks in the product, workspace creation can be gated by billing or trial state, and chat consumes a credit before model work begins. That makes operational problems easier to diagnose, and it reduces the chance that a UI label is mistaken for the whole permission model.

The manual can be confident about the current shape of the product, but it should stop where the repository evidence stops. Document capture, extraction, and some integration behavior are visible enough to describe as product workflows, yet they may cross into processing or provider boundaries that are not fully contained here. That boundary is a strength because it keeps the manual honest: it can describe what the owner will see and decide against, while still marking the places where the deeper machinery may live elsewhere.

That honesty matters in practice. If a document upload succeeds but downstream processing behaves oddly, the owner should know that the visible workflow is only part of the story. The manual does not need to invent the hidden machinery to be useful; it only needs to say, precisely, that the workspace model, navigation, permissions, creation gates, membership control, and credit handling are solidly established, while extraction and some integration paths remain bounded by what the reviewed evidence proves.

The reviewed code shows one workspace flow: the web app drops you into Statements, web and mobile both upload a file before extraction starts, and the extracted statement only becomes durable transaction data when reconciliation is completed. From there, the Transactions page edits the reconciled ledger and Reports read the same ledger. This is built from the code, so it shows what the app does today, not the intent you may still need to confirm.

• Explain why Statements is the starting point for this part of the product.
• Explain the path from upload to extraction to review to reconciliation to trusted transaction data.
• Explain which steps are guarded, retry-based, or destructive, including duplicate handling and reopen.
• Explain how web, mobile, Transactions, and Reports fit into one shared bookkeeping story.

Statements is the front door for this part of the product. The workspace opens there by default, so imported activity begins in the same place the owner is expected to review it. That matters because it gives the product a single starting point for statement work instead of scattering intake across different screens. If you are trying to understand where imported documents become bookkeeping work, start by thinking: statements enter first, everything else follows.

Web and mobile are two surfaces on the same workspace-scoped intake flow, not separate bookkeeping systems. The practical consequence is that a document captured on mobile and a file uploaded in the web app belong to the same bookkeeping story once they enter the workspace. The owner does not need to treat them as two ledgers or two independent queues; they are two doors into one pipeline.

A useful way to picture this is that the device choice changes how the document gets into the workspace, but not what kind of bookkeeping object it becomes. A member might snap a receipt on the phone while traveling, then later review the same workspace in the web app. Those are different moments in capture, but not different accounting worlds.

The real handoff happens at reconciliation completion. Before completion, statement work is still in review: it may be extracted, checked, corrected, or left unresolved. After completion, the same activity stops being just a statement record and becomes durable transaction data. That is the point where the app treats the work as ready to live in the bookkeeping ledger.

This is why completion carries so much weight for the owner. It is not just a status change in the UI; it is the step that turns reviewed statement activity into the accounting record the rest of the product can trust. The boundary is important too: incomplete work is still provisional, and the manual should not treat it as final just because it has been imported or partially processed.

Transactions and Reports sit downstream of that reconciled ledger. Transactions is where the owner works with the reconciled records directly, and Reports read from the same underlying set. That means later changes to reconciled transactions can move what the owner sees in both places. If a category is corrected or a matched document is adjusted after reconciliation, the ledger changes, and the downstream views reflect that change.

That shared source is the main mental model to keep. The product is not maintaining one story for Transactions and a different story for Reports. It is keeping one bookkeeping spine, then showing it through different lenses. So if a number shifts in a report, the right question is usually not "which screen is lying?" but "what changed in the reconciled ledger?"

In practice, this gives the owner a simple rule: review happens in Statements, finalization happens at reconciliation completion, and everything after that is a view onto the same committed bookkeeping data.

In practice, that means the client has to finish the handoff to storage before it can ask for bookkeeping work. A member cannot skip straight from choosing a document to a processed statement. The document has to exist in the intake pipeline first, and only then can the workspace ask the extraction service to do its job.

The duplicate-upload check is different. It is helpful when it works, but it is not the main gate. If the system can confirm that the file was already processed, it can treat the extraction as a duplicate and stop that path. If the duplicate lookup itself fails, the job still continues to enqueue. That is the boundary the owner needs to understand: duplicate suppression is best-effort, not a hard guarantee. So a temporary lookup failure can still let another extraction job through and consume more work or credits.

While extraction is still unresolved, the product keeps polling until the job settles into a terminal state. That means the system does not guess early. It waits for the non-terminal work to finish, then either records the successful result or leaves the job in a failed state. For the owner, that separates “work in progress” from “work that has become part of the books.”

The run then follows a polling loop. The page keeps checking while the run is pending or in another non-terminal transient state, and it stops only when the outcome is terminal or the attempt times out. That gives the owner a controlled finish line: the system can wait, retry, or block, but it does not silently announce completion before the run has settled.

A simple example makes the flow concrete. A member uploads a statement, the file is staged through the signed upload path, extraction is requested with the workspace metadata, the system blocks the request if the workspace is locked or the credits are not available, and a duplicate check only stops the job when it can confirm the repeat. If extraction succeeds, the result is stored and credits are charged afterward. If the statement is still in progress, reconciliation can then start and keep polling until it either finishes cleanly or times out.

The evidence makes the workspace shape and its role gates concrete. Statements is the default landing place in the web shell, and the main navigation groups the bookkeeping surfaces together: Dashboard, Statements, Expenses, Transactions, Reports, AI Bookkeeper, Contacts, Chart of Accounts, and Workspace Settings. That matters because the product does not hide the statement flow behind a separate entry point; it presents it as the first stop in the bookkeeping workspace, with the other surfaces arranged around it.

A concrete case makes the boundary clear. If a month-end statement still has one unresolved line, completion should stop there. If that same statement is otherwise ready and the workspace is on version 3, the absence of a payee does not necessarily block completion, and the product may create the contact record it needs during that finish step. That is a bookkeeping rule, not a cosmetic one, because it determines what becomes trusted ledger data.

The important pattern is that the same bookkeeping surface carries different gates depending on the action. Editing a transaction, finishing a reconciliation, and reopening a locked reconciliation are related, but they are not interchangeable. An owner who needs to fix a finalized period has a privileged reopen path; an active member can still work the ledger inside the normal reconciliation flow; a viewer can only observe.

Statements still lead the workspace, but bills, invoices, and receipts run as a parallel lane beside them. In web and mobile, the product first stages the upload, then starts extraction, and only after that writes the extracted data back into workspace records. That means the document is not trusted at capture time; it becomes useful only after the review path finishes. The reviewed evidence also shows this flow can touch contacts and other bookkeeping records, but it does not prove a separate bill-category model, so that boundary stays with the controls chapter. Two owner risks are already visible: duplicate-file checks can miss when the lookup fails, and bill cleanup can stop halfway through.

• Explain that bills, invoices, and receipts are one document lane beside statements, not a separate product.
• Explain the upload -> extraction -> review sequence and where a document becomes trusted.
• Explain which checks block extraction and where duplicate detection is only best-effort.
• Explain the main cleanup and state risks that can leave partial or duplicated expense-document work.

That framing matters because it keeps the product model consistent. Statements remain the main spine of the workspace, but expense documents are not outside that spine; they are adjacent to it. For an owner, that means the question is not "Which product should I use for bills?" but "Which intake path should I use for this document type?" The answer is that bills and receipts follow their own lane, while still belonging to the same workspace story.

That sequence is the owner-visible boundary. If processing is still running, the safest assumption is that the document has not yet finished becoming part of the bookkeeping record. Once extraction completes, the document can contribute usable information back into the workspace. This is why the flow is designed as intake first and usefulness second, rather than as an instant write-through capture tool.

A simple example is a supplier receipt captured on the way out of a meeting. The upload may succeed quickly, but the owner should still treat the receipt as pending until extraction finishes. Only after that point does it become something that can be relied on as part of bookkeeping work.

That is useful because it helps the workspace turn a receipt into something operational, not just archival. A document that identifies a vendor can contribute to contact records, and related bookkeeping data can be enriched as part of the same flow. For the owner, that means the value of this lane is not only document storage. It is the chance to connect imported expense evidence back to the bookkeeping structure the workspace already uses.

The boundary is important, though. The evidence supports contact and related-record enrichment, but it does not establish a separate bill-category model here, so that belongs with the controls chapter rather than this one. The safe mental model is therefore simple: expense documents are a parallel intake lane that starts as a candidate, becomes useful after extraction, and then joins the same bookkeeping world as contacts and other related records.

For the owner, that split matters because it changes what counts as a real submission. A document that has been selected but not successfully staged is still just an attempt. The system only has something it can work with after the upload step completes and the extraction starter has enough workspace-scoped context to proceed. This is also where the chapter stays separate from statement-specific reconciliation: the same bookkeeping product has another document lane, but this section is only about the document intake path that precedes extraction.

That behavior matters because it keeps the intake lane from turning into an expensive catch-all. A locked workspace should not keep accumulating document work, and a member without the right workspace standing should not be able to push extraction through by accident. Low credit is treated the same way: the system refuses to start work it already knows it should not fund. The boundary is that these are start-time checks. They tell you what can be queued, not how a later review should interpret the document once it exists.

For the owner, the consequence is simple but important. Duplicate protection reduces unnecessary work when it succeeds, yet an outage or lookup failure in that check can still allow another extraction job to be created. That means duplicate handling is not a guarantee against repeated work or repeated charging pressure. The evidence does not establish whether that should remain the long-term policy; it only shows that the current path prefers progress over stopping the intake lane when the lookup is unavailable.

That order changes the owner’s risk profile. A successful extraction is meant to leave durable bookkeeping data behind even before the credit side is settled, so the product is not depending on billing timing to make the document useful. The boundary is equally important: the evidence shows this write-first pattern on the successful path, but it does not prove every downstream bookkeeping detail or every enrichment rule. What is established is narrower and still useful: the system stores the extracted result before it charges for that work.

A concrete example helps. Suppose a member uploads a receipt from the web app while the workspace is active and the file passes validation. The upload is staged, the extraction starter checks that the member is allowed to proceed, and the job is queued. If the duplicate lookup is unavailable at that moment, the job may still go through. If extraction later succeeds, the product saves the result, may update the related contact or financial account data, and only then reduces the credit balance. If any of the start checks fail instead, the document never reaches the queue at all.

The owner-facing implication is simple: statement deletion is more carefully guarded, while bill deletion can be only partly successful. In the bill case, a failure midway is not treated as impossible by the evidence we have; it is an explicit risk. That is why the bill path should be read as cleanup in stages, not as an all-or-nothing operation.

That consistency is not just cosmetic. In practice, it keeps training and support simpler, and it makes the owner’s process easier to standardize across a team. If someone is traveling and captures a receipt on mobile, the owner can still expect it to enter the same workspace flow later, instead of turning into a side path with its own behavior. The boundary is important: this does not prove that every downstream bookkeeping outcome is identical in every case, only that the capture contract itself is shared and coherent across the two surfaces.

That early gate also protects the bookkeeping lane from becoming noisy. If a workspace is locked, or the caller is not allowed to operate in that workspace, the flow stops at the edge instead of producing half-finished document work that someone has to untangle later. The one important qualifier is duplicate detection: it is only best-effort. So the system is strong at stopping clearly invalid starts, but it is not perfect at preventing a duplicate when the lookup itself does not come back cleanly.

This makes the flow more resilient to timing problems. Suppose a receipt finishes extraction and the workspace record is written successfully, but the credit deduction happens afterward. The owner still has the extracted bookkeeping data even if the billing step is delayed or has to be retried. The system is therefore less fragile than a design that charges first and only later tries to save the result, because a billing hiccup would not erase the completed bookkeeping work. The limit is narrow but important: this is a durability advantage, not a guarantee that every later step in the surrounding workflow is free of cleanup risk.

This chapter is built from the code, so it shows what the app does today, not what you may want it to mean. In the workspace shell, Statements is the default entry point and the same navigation exposes Transactions, Reports, AI Bookkeeper, Contacts, Chart of Accounts, and Workspace Settings. The bookkeeping controls here are shared: changing categories, contacts, or reconciliation state changes the transaction ledger the rest of the product reads from. That is why this chapter focuses on control, not decoration: these edits decide whether the numbers stay trustworthy.

• Explain that categories, contacts, and the chart of accounts are shared bookkeeping controls, not isolated labels on one screen.
• Explain which bookkeeping actions change the ledger directly and which roles can do them.
• Explain how reconciliation completion, reopen, and transaction edits affect report output.
• Decide whether the current edit and reopen rules are strict enough for the trust you want.

Think of the bookkeeping area as one shared control layer in the workspace. The shell does not hide bookkeeping behind a settings-only corner: Statements is the default landing surface, and the same navigation path also exposes Transactions, Reports, AI Bookkeeper, Contacts, Chart of Accounts, and Workspace Settings. That layout matters because it tells you what the product believes these areas are for. They are not isolated tools that happen to sit next to each other. They are the working surfaces that shape, read, and govern the same accounting record.

The practical consequence for an owner is that the bookkeeping flow has a single center of gravity. If a category changes, if a contact is corrected, or if the chart of accounts is adjusted, that is not only a visual cleanup on one page. It changes the meaning of the underlying record that other parts of the workspace will later read. The chapter on transaction handling explains the edit mechanics and role gates; here, the important mental model is simpler: these controls are shared structure, so a change in one place is not local to that one screen.

Categories and contacts matter because they carry accounting meaning, not just presentation. A category tells the product how to interpret a transaction for bookkeeping purposes. A contact ties the transaction to a person or business relationship that can be reused across the workflow. When those shared records are correct, the product can present a transaction as something stable and intelligible instead of as a raw line item with missing context. When they are wrong, the problem is not cosmetic. The record itself becomes less trustworthy, and every downstream view that depends on it inherits that weakness.

The same is true of the chart of accounts. It is part of the product’s explicit accounting structure, so it is best understood as the vocabulary the workspace uses to sort financial activity into the right buckets. That vocabulary does not live on one page only. It is the structure that lets the rest of the bookkeeping layer speak consistently about the same transaction over time.

The owner should read Transactions and Reports as two views over the same underlying bookkeeping state, not as two separate systems with their own version of the truth. The transaction page reads from the reconciled transaction set, and the report views are built from that same set with the chosen date or fiscal window applied. That means a change to shared bookkeeping structure does not stay confined to the editing surface. It shows up wherever the workspace reuses the same record.

A concrete example: if a transaction is recategorized, the immediate effect is not only that the transaction looks different in the transaction list. The category change can also alter what later report views count, because those views are reading from the same source record. This is why governance over shared controls matters. You are not deciding whether a label looks neat; you are deciding whether the bookkeeping record remains consistent enough for reports, reconciliation history, and AI-assisted answers to mean the same thing when they read it later.

The boundary is worth keeping clear. This section is about the mental model of the control layer, not the step-by-step edit flow or permission matrix. The point is that the workspace has one shared bookkeeping spine, and categories, contacts, and the chart of accounts are the structure that makes that spine usable.

The practical split here is between ordinary ledger edits, reconciliation finalization, and reversal. The system lets some roles change bookkeeping records in place, but it keeps reopening much narrower because reopening undoes a completed state instead of simply correcting a line.

The permission boundary is easiest to see in a single matrix. Editing transactions and completing reconciliations are available to active members and admins, while reopening a locked reconciliation stays with owner and admin roles. Viewers have no write path.

That split matters because it is an action gate, not a cosmetic label. Two people can look at the same bookkeeping record and still have different options depending on role. For the owner, the consequence is that ordinary correction work does not require full reversal rights, but the right to reopen a locked reconciliation remains reserved for the stronger roles.

Transaction edits write back to the same reconciled transaction records that the product uses for downstream work. They are not edits to a shadow copy or a temporary review layer. When a member or admin changes a category, the change lands on the live bookkeeping record. When they adjust a matched-document link, that link changes in place as well. The owner should read that as a direct control over the meaning of the transaction, not just its presentation.

The consequence is immediate. If a charge was categorized as travel and later corrected to software, the corrected category is now the shared record other parts of the product see. That is useful because it keeps the bookkeeping state consistent, but it also means a mistaken edit is not isolated to one screen. The boundary the evidence establishes is specific: the reviewed transaction path clearly updates category and matched-document fields in place. It does not establish every editable field or every possible bulk-edit pattern beyond that.

Completion is stricter than editing. A reconciliation only completes when unresolved items are cleared and the required fields are present. In the reviewed completion path, that means category, date, and payee information are expected before the record can be finalized. There is one important qualifier: the newer completion path can allow a missing payee and still create the final transaction records and contacts. The evidence does not show that every completion path is equally permissive; it shows an alternate path that relaxes payee presence while still producing durable bookkeeping data.

For the owner, that is the line between review work and accounting truth. If the reconciliation is not valid enough, it stays open. If it is valid enough, the product turns it into final transaction records, and the contacts record can be created or revived as part of that closeout. A concrete example helps: if a statement line has a clear amount, date, and category, but the payee was not captured, the newer completion path can still finish the reconciliation instead of forcing the work to stop at a missing name.

Reopening is the reverse of finalization, so it is narrower than ordinary editing. The reviewed interface only offers reopen for locked reconciliations, and the privileged path is limited to owner and admin roles. That means a viewer cannot reopen anything, and an active member cannot undo a locked closeout even if they were allowed to complete it earlier.

This separation is important because reopening changes the trust level of the bookkeeping record. A completed reconciliation is meant to behave like durable accounting data until someone with stronger authority decides it should be reviewed again. The boundary is also clear: the evidence covers locked reconciliations. It does not say that every other state exposes the same reversal control.

Report views read from the same transaction ledger and then apply the selected date or fiscal window. The practical effect is that a control change in transactions or reconciliation can show up in more than one report tab without any separate reporting edit. The report set includes Transactions, Profit & Loss, Balance Sheet, Spending, General Ledger, and Trial Balance, so a single correction can surface across several different views of the same underlying records.

That matters because the reports are not independent bookkeeping copies. If a correction changes the ledger, the report numbers for the matching window move with it. For example, if a March transaction is re-categorized and the report is set to March, the Spending view and the profit-and-loss view can both reflect the new categorization. The boundary is the window: changing the selected period changes what you are looking at, but it does not create a separate version of the bookkeeping record.

A practical way to read this is that an owner who opens the workspace should expect to begin from statement work and then move directly to transactions, reports, contacts, or the chart of accounts without changing product context. The evidence does not establish the full visual design of the shell or every possible navigation state, but it does establish the default landing point and the set of sections the shell exposes today.

The consequence is straightforward: if a transaction is being looked up by payee, category, or timing, the page gives a direct way to reduce the visible set before editing or reviewing. The evidence stops short of proving every possible filter combination or sort behavior, so the safe reading is limited to the filters that were actually observed. Even with that boundary, the underlying point is strong: the Transactions page is meant to help people work against the live ledger, not a separate copy.

For an owner, the important consequence is that the page can support both operational checking and formal financial review. A Spending view may help spot where money is going, while General Ledger and Trial Balance are more structural accounting views. The evidence does not say how much each tab can be customized beyond the date or fiscal window controls that are known elsewhere in the reviewed set, so this section stays with the fact that these views exist and are part of the same report surface.

This matters because it shows the product can repair or restore contact records as part of finalization instead of leaving them stranded in a half-finished state. A concrete example is a statement line that was matched and completed with a payee that had previously gone missing from the active contact list: the completion flow can still materialize the final transaction and bring the contact back into play. The evidence does not prove every possible reconciliation outcome or every reason a contact might change, but it does prove that finalizing review can produce final transactions and affect contacts before the interface returns to the statement detail screen.

Use this chapter when you want to know which numbers the app is actually showing you. The Reports area reads from the same reconciled ledger that the Transactions page edits, so a transaction change or a completed reconciliation can move the numbers you see. The workspace menu also shows AI Bookkeeper, but the reviewed evidence only proves that label exists in navigation; it does not yet prove the full question-and-answer flow behind it. This chapter is built from the reviewed code, so it tells you what the app does today, not what you mean it to be.

• Explain that reports are downstream reads from the same bookkeeping ledger that Transactions updates.
• Name the report views the app exposes and the windowing that shapes them.
• Tell when report numbers can move because of transaction edits or reconciliation completion.
• State what is and is not verified about the AI Bookkeeper entry in this evidence set.

That matters for ownership because it changes how you explain a surprise. If a report looks wrong, the first question is not “which report is broken?” It is “what changed in the bookkeeping that the report is reading?” In practice, that means the report page is not a place where numbers are manually curated away from the rest of the product. It is the place where completed bookkeeping becomes visible in summary form.

For an owner, the consequence is simple but important. A report is trustworthy only to the extent that the bookkeeping beneath it is current. If a category changes, a transaction is corrected, or a reconciliation is finished, the report output can shift because it is reflecting the updated bookkeeping state. The boundary is equally important: Reports do not prove that the underlying work was right, only that they are faithfully reading the current completed records.

A concrete example makes this easier to hold onto. Suppose a transaction was initially categorized as travel, then later corrected to software. The report does not need a special refresh rule or a separate approval path to notice that change; it will show the effect because it is reading the same bookkeeping base. Likewise, if a reconciliation is completed after a period of review, the reports that depend on those records can change immediately because the bookkeeping has moved from provisional to completed.

That framing is the right way to read the workspace. Reports are where completed bookkeeping shows up as financial output. AI Bookkeeper is another reading surface in the same workspace, so it should be judged against the same upstream discipline: the quality of the imported, categorized, and reconciled bookkeeping underneath it. If those upstream records are incomplete or still changing, both surfaces need to be treated with the same caution. If the records are complete, both become more useful because they are drawing from the same governed source of truth.

Reports are not frozen summaries. The page reads the same reconciled bookkeeping base that the Transactions area updates, then it applies the current reporting window before it shows or exports the result. That means two things can legitimately change what an owner sees: the underlying bookkeeping record can change, or the selected reporting window can change. The report pages are therefore best understood as a live view over completed bookkeeping, not as a separate place where numbers are edited by hand.

A practical example helps. Suppose June spending looks too high because one transaction was categorized incorrectly. Once that transaction is edited on the Transactions page, the next spending report for June should reflect the corrected category instead of preserving the earlier mistake. The report is not preserving history for its own sake; it is showing the current bookkeeping state for the chosen period.

The boundary is important. Before completion, a reconciliation can still be in progress and may still be changing. Reports can only be as reliable as the state below them, so an owner should expect report confidence to rise only after the reconciliation is finalized. In other words, reports do not certify the bookkeeping for you; they reflect the certification that happened upstream. If a reconciliation is reopened later, the underlying record can change again, and report numbers can move with it.

A concrete example makes the consequence plain: if someone opens a fresh workspace, they do not start in Reports and then hunt for where the ledger lives. They arrive in Statements first, and Reports is one of the peer sections in the same navigation set. The evidence here stops at that navigation fact. It proves that AI Bookkeeper appears in the shell; it does not, by itself, prove the full question-and-answer behavior behind that label.

For the owner, the practical boundary is that each report view is a readout of the same bookkeeping base, filtered for a reporting window. If the window changes, the numbers can change even when the underlying bookkeeping has not. If the bookkeeping changes, the report output can change even when the window does not. The evidence is specific about the available views and the windowing behavior; it does not claim any additional report family beyond the six named here.

That matters because the owner should not think of Transactions as a separate staging area. An edit made there is a bookkeeping change, not a copy-only annotation. If a member corrects the category on a transaction, that change is applied to the ledger the reports depend on, so the effect can show up downstream. The evidence is careful here: it establishes the write path and the role boundary, but not a broader claim about every possible transaction field or every UI action in the product.

The same completion step can also create or revive contacts when validation passes. That means reconciliation is not only a finishing stamp on the statement; it can also leave behind normalized bookkeeping objects that other parts of the product can use. A simple scenario shows why this matters: if a statement line had no durable transaction record yet, completing the reconciliation turns it into one, and if the contact was missing or previously inactive, the completion step can restore it as part of that finalization. The evidence does not go beyond those conditions, so it should not be read as a promise that every reconciliation will always create contacts or that completion can bypass validation.

This chapter covers the support layer around bookkeeping: the workspace shell, who can change it, and which limits can stop work before it starts. In the reviewed behavior, the workspace opens on Statements first and then shows Dashboard, Expenses, Transactions, Reports, AI Bookkeeper, Contacts, Chart of Accounts, and Workspace Settings; the workspace owner/admin/member/viewer split decides who can invite people, edit settings, or touch integrations. Billing limits and the Xero boundary sit at the edge: they can stop a new workspace from being created or leave an integration visible in backend behavior even when the UI has disabled it. This is built from the code, so it shows what your product does today, not what you mean it to be - that part is yours to confirm.

• Explain why Statements is the default entry into the workspace and what sits around it.
• Describe the difference between workspace owner, admin, member, and viewer without flattening the roles.
• Tell which actions are enforced in the client, which depend on backend policy, and which use separate invite or integration paths.
• Recognize when billing limits or a disabled integration can still affect the workspace.

Think of the workspace as the control layer that holds the bookkeeping world together. It is where the product keeps the active bookkeeping data, the people allowed to work in it, the settings that define how it is read, and the limits that can stop new work from starting. That is a different job from a generic admin dashboard. A dashboard usually just summarizes what already exists. The workspace here is more structural: it is the boundary around the work itself, and the rules around it shape what can happen next.

That framing matters because it keeps you from treating workspace administration as a side panel you can ignore. If the workspace is misconfigured, locked, or capped, the effect is not cosmetic. It changes whether the product can accept new work, whether someone can invite another person, or whether a connected service remains available at all. The manual should therefore read the workspace as an operating boundary around bookkeeping, not as a separate product from bookkeeping.

The default path into the workspace is Statements. The rest of the navigation sits around that center: Dashboard, Expenses, Transactions, Reports, AI Bookkeeper, Contacts, Chart of Accounts, and Workspace Settings. The consequence for an owner is simple but important. The product is organized so that statements are the first thing you land on, while the other sections support the work that grows out of them.

That order is a signal about the product's center of gravity. Statements is the place where bookkeeping work begins, and the surrounding sections are the paths you take once that work needs review, categorization, reporting, or administration. A concrete example: if a member opens the workspace to continue month-end cleanup, they are not entering a settings console and then searching for the accounting work. They are entering the bookkeeping flow first, with settings and other sections available when the work requires them.

The workspace role split is part of that control layer. Workspace owner and admin sit on one side of the boundary: they can govern the workspace. Member and viewer sit on the other side: they cannot. The exact shape of every action belongs in the permissions section, but the mental model is straightforward. The first pair is allowed to manage the workspace; the latter two are not the people who change membership, settings, or the workspace's operating rules.

The important practical consequence is that role labels are not decorative. They determine who can move the workspace forward when a change is needed. If a business owner expects a viewer to make configuration changes, that expectation will fail. If a member is meant only to do bookkeeping work inside the workspace, that narrower scope is intentional. This is why the manual should keep owner and admin distinct from member and viewer instead of flattening them into one broad notion of access.

Billing limits, trial state, and the Xero boundary should be treated as edge conditions, not as the product's identity. They matter because they can interrupt work, but they do not define what the product is. Workspace creation can be gated by billing state, and the first workspace can start a seven-day trial. That means the product has a support layer around entry and growth: it can allow the first workspace to boot into trial resources, while still enforcing workspace-count limits when the billing data is present.

That same pattern appears in the Xero boundary. The visible UI is disabled, but the backend path is still present behind checks. In practice, that means a connection can remain a live boundary even when the screen suggests it is off. For an owner, the lesson is not that Xero is the core of the workspace. It is that external integrations can still shape behavior at the edge, and a disabled screen does not always mean the underlying boundary has been removed.

A useful way to picture this is to imagine a new company setting up its first workspace. The trial starts automatically, the workspace appears under the normal bookkeeping navigation, and the team can begin work in Statements. If that company later hits a billing cap or encounters the Xero boundary, the workspace still remains the same workspace. What changes is whether a particular edge action is allowed, not the identity of the product itself.

The role boundary in this workspace is not mainly about what people can see. It shows up when they try to change the workspace itself, add or remove members, or cross into an external integration. The shell lets people move among workspaces from the same top-level surface, and it can also block creation of a new workspace when the account state does not allow it. That means switching is part of ordinary navigation, while creating a new workspace is a separately gated step.

Owner and admin sit on the same side of the operating line today. Member is narrower, and viewer has no operational access. The practical difference is what happens when someone tries to save settings, manage people, or touch an integration boundary. The table below shows the current split in the places that matter most to an owner.

That boundary is enforced in two layers. For member management, the checks happen at the action level: the settings screen will block invite and manage actions when the role does not qualify, and the membership changes themselves travel through separate invite, accept, decline, and remove paths. An invite must be created first, then accepted or declined with the matching invite details, and removal is its own path. The remove path also refuses to remove the owner, so the top role cannot be stripped away through the ordinary member-removal flow.

Workspace settings behave differently from membership changes. A settings save goes straight to the workspace record on the server, and the server applies the admin-only update rule if the write reaches it. That is why owner and admin behave the same for workspace settings today, while member and viewer do not. For the owner, the consequence is simple: a visible settings form is not the same thing as write access, and the real guard lives at the action and server layers together.

Xero is the clearest example of a visible boundary that is still partially alive. The tab is disabled in the UI, so the workspace does not present Xero as an active in-app path. Even so, backend authorization, callback, and disconnect paths still exist behind edit-right checks, which means the integration is not erased so much as hidden from ordinary navigation. For an owner, that matters because a disabled surface does not always mean the backend boundary has been removed; it can still hold state and still change if the checked paths are reached.

A concrete way to read this is to imagine three people in the same workspace. The owner can change workspace settings, invite a member, and manage the integration boundary. An admin can do the same. A member can work in the workspace but does not get the administrative controls, and a viewer can only observe. If the workspace is blocked from creating a new workspace, that is a separate account-level gate, not a signal that existing workspace switching has broken.

The table below keeps those states separate because the product treats them differently even when they all show up at the same creation step. It shows where creation is a bootstrap event, where a billing limit is merely available to be enforced, and where the action is blocked before the workspace is inserted.

The important reading is that the first workspace is a bootstrap event, not just another create action. It gets the trial started. Later creation is governed by billing quantity only when that quantity is present, so missing billing data does not automatically stop a workspace from being created. That is the narrow boundary the review establishes: quota enforcement exists, but a missing quantity does not become an automatic veto. In practice, that means a billing-data gap can fail open instead of turning into a hard stop, while locked and already-active trial states still fail closed.

Xero sits at a different edge. The integration tab is disabled in the UI, so the product does not present Xero as an active visible path. Even so, authorization, token exchange, and disconnect handlers still exist behind backend checks. The reviewed evidence does not prove whether the disabled tab is temporary or permanent; it only confirms that the visible surface and the backend path are not the same thing.

A concrete case makes the boundary easier to read. If an owner opens Workspace Settings and changes the currency and fiscal year, the form exposes those fields, but the save still depends on the admin-only server rule. If the same owner looks for Xero in the shell, the tab is disabled, yet the backend integration logic has not disappeared. The owner should therefore treat the shell as the front edge of the workspace and the server policy as the real gate for what actually changes.

The boundary here is important. This strength is not that every workspace task is exposed at once, or that the shell solves bookkeeping itself. It is that the product gives the owner a stable operating frame. That reduces friction for training, support, and day-to-day use, because the surface area is organized around the bookkeeping flow rather than around account administration for its own sake. A support person can tell a customer, "Open the workspace and start from Statements," and that instruction maps cleanly to the product as reviewed.

That structure matters operationally. If a collaborator never joined, the invite can fail before it becomes a live membership. If someone is invited but does not respond, the workspace still has a record of the pending boundary. If a member leaves, removal is distinct from invitation and distinct from acceptance. A concrete example: you can invite a bookkeeper to help during month-end close, they can accept when ready, and if they later step away, the workspace can remove that membership without threatening the owner position or making the change look like a general settings edit. The review confirms those separate paths, but it does not claim the whole membership policy universe is exposed here; it only establishes that the important boundaries are visible.

This distinction matters because it changes how the owner should read a limitation. If creation is blocked, the issue is about account status or workspace limits. If Xero is disabled in the UI, the feature is not necessarily deleted; it may be intentionally hidden while some protected integration path still exists. In practice, that means the owner should not assume that every disabled control means permanent removal. It may simply mean the visible route is closed. The review supports that reading for Xero, but it does not establish why the feature is disabled or whether it is meant to return.

For the owner, this honesty is not a weakness; it is what makes the rest of the chapter trustworthy. The manual can describe what is actually enforced, where a boundary is visible, and where the system still leaves room for change. When a behavior is clearly established, it is stated plainly. When the evidence stops short, the section stops short too. That is the right tradeoff for a workspace layer whose job is to support bookkeeping, not to invent a broader governance story than the product has confirmed.

The mobile app is the on-the-go companion to the same bookkeeping product, not a separate product line. On mobile, you can capture receipts or bills, review documents, chat with AI, and switch workspaces, while the web workspace remains the place for statements, transactions, reports, and settings. When mobile captures a file, it uploads first and then joins the shared extraction flow; when mobile chat is used, it spends workspace credits before it answers. This is built from the code, so it shows what your product does today, not what you mean it to be, and that part is yours to confirm.

• Explain why mobile should be treated as a companion surface rather than a full replacement for the web workspace.
• Describe the mobile capture and document path in plain terms, including where upload and extraction happen.
• Explain the limits and cost boundary on mobile AI chat.
• Identify where workspace switching lives on mobile and when deeper bookkeeping work should move back to web.

Think of mobile as another surface on the same bookkeeping product, not as a separate account system or a trimmed-down sibling business. The important idea is continuity: the same workspace identity follows the work across phone and web, so what happens on mobile still belongs to the same bookkeeping space that holds statements, transactions, reports, and settings. That means the owner does not have to mentally translate between a “mobile account” and a “web account.” There is one workspace, and mobile is simply one way into it.

That matters because it changes how you judge work done on the phone. A receipt captured on mobile is not a side note to be reconciled later in some different system; it is part of the same workspace flow. Likewise, mobile chat is not a separate assistant with its own memory and rules. It is the same workspace-scoped AI story, just accessed from a portable surface. The boundary is that mobile does not establish a parallel bookkeeping home of its own. It inherits the workspace model rather than replacing it.

Mobile’s job is to keep bookkeeping moving when the owner is away from the desk. It is built for on-the-go capture, quick document review, AI chat, and workspace access. That is the useful mental model: mobile is where work starts cleanly, gets checked quickly, or gets answered in the moment, but it is not where the entire bookkeeping process is supposed to live.

This is why the mobile app is worth using even though it is not the full workspace. A phone is the right place to catch a bill or receipt before it is lost, to confirm that a document has reached the right workspace, or to ask a narrow question without waiting to sit down at the computer. In practice, that shortens the distance between seeing a document and getting it into the bookkeeping flow. The qualifier is important: mobile helps move work forward, but it does not pretend to be the full bookkeeping desk.

A simple example makes the split clear. A member can capture a receipt on the way out of a meeting, glance at the document on the phone, and ask the AI Bookkeeper a quick question about it. That is enough for motion. Later, when the owner wants the broader bookkeeping picture, they move to the web workspace to work through the statements, transactions, reports, and settings that define the fuller desk experience.

The web workspace is still the place where the broader bookkeeping surface lives. Statements open there by default, and the deeper working areas are there as well: transactions, reports, and workspace settings. So the right way to read mobile is as a handoff surface, not a replacement surface. It receives work when the owner is away from the desk, but the main bookkeeping view still belongs to web.

That distinction protects expectations. If you treat mobile as a full replacement, you will ask it to do the wrong job and be disappointed by the result. If you treat it as a companion, the behavior makes sense: mobile is for capture, quick review, AI chat, and workspace switching when needed; web is for the broader bookkeeping work that needs more space and context. The owner-facing consequence is practical: mobile keeps the workflow alive, while web remains the place to finish and review the parts of bookkeeping that are meant to be read as a whole.

The table shows the shared shape underneath the different screens. Capture and Documents are two faces of the same ingest route: the file leaves the device first, then extraction takes over. Documents is the more obviously status-driven path because it keeps polling after upload, but the important boundary is the same in both places: the mobile app is handing work into the workspace flow, not storing it in a separate phone-only queue.

AI Chat works differently from capture, but it is not free-floating either. The client sends the workspace and session identity together, and the server decides whether the message can proceed at all. That check is not just about being signed in. It also rejects archived or locked workspaces, applies daily and per-session limits, and deducts one chat credit before the model work starts. If credit cannot be deducted, the stored user message is removed rather than left behind as if the chat had succeeded. For an owner, that means the cost boundary is enforced before the answer is produced, not after the fact.

Workspace switching stays in Settings for a reason. On mobile, switching is a controlled action, not a constant background choice, and it only appears when the app can actually offer more than one workspace. That keeps the home surfaces simple while still letting a member move between workspaces when they have access to more than one. A practical example is a bookkeeper who opens Capture in the wrong client workspace, notices the mismatch, and switches inside Settings before uploading the receipt. The correction happens inside the same mobile companion, but the bookkeeping work still lands in the right workspace.

What matters overall is the division of labor. The mobile paths are separate jobs, but they all resolve into the shared workspace flow. That is why the phone can be useful on the move without pretending to replace the deeper bookkeeping surfaces on the web.

The boundary is important as well. The evidence confirms these tabs, but it does not establish any broader mobile navigation. So the safe reading for an owner is simple: if a task is not reachable from those surfaces, it should not be assumed to exist on mobile just because it exists somewhere else in the product.

For an owner, the consequence is operational clarity rather than feature breadth. If a member works across multiple client workspaces, the switch does not appear as a general navigation control on every screen. It appears only when the product has more than one workspace to choose from, and the switch itself lives inside Settings. That keeps the mobile surface focused on the current workspace rather than on workspace administration.

A concrete example: a member opens the app for the first time and the first available workspace becomes active without extra setup. If that member later needs a different workspace, they go to Settings and switch there. The evidence does not establish any other mobile entry point for workspace switching, so anything beyond that should be treated as unconfirmed.

For the owner, this creates a clean division of labor. Mobile is the smaller, faster surface; web is the fuller working environment. If someone needs to move from capture or chat into broader statement review, transaction editing, reports, or workspace setup, the reviewed navigation points them back to web rather than trying to make mobile carry that entire load.

A practical scenario makes the boundary visible: a receipt is captured on the phone, but the next step is not to expect every downstream bookkeeping view on mobile. The supported handoff is to the web workspace, where Statements is the landing point and the rest of the bookkeeping sections are available. This section only confirms that handoff shape; the detailed statement and transaction workflow belongs elsewhere in the manual.

Mobile is strongest where it draws a clean line and then stays inside it. The companion surface uses one workspace identity, one document capture path, and one AI credit rule, so the owner is not dealing with three different versions of the same product idea. That matters because the mobile app does not feel like a loose preview or a separate account system; it behaves like the same bookkeeping workspace viewed through a smaller, faster doorway. In practice, the app loads the user’s workspaces, chooses one as active, and keeps workspace switching inside Settings when there is more than one workspace available. That gives the owner a stable frame: when they move from phone to web, they are still operating in the same workspace, with the same bookkeeping boundaries.

The scope is also honest. Mobile is built for quick capture, document status, chat, and workspace access, not for pretending to reproduce the full web workspace on-device. That is a strength because it reduces false expectations. The app does not have to carry the entire statements, transactions, reports, and settings surface to be useful. Instead, it does the things that are most valuable when the owner is away from the desk: catch a receipt or bill, check whether a document has progressed, ask a question, or move to another workspace. A simple example makes the boundary clear: an owner can photograph a bill on the road, see that it has entered the document flow, ask AI a question tied to the current workspace, and then later return to the web workspace for deeper bookkeeping work. The mobile app stays useful precisely because it does not try to own the whole job.

The shared enforcement is what makes the behavior easy to reason about. Mobile capture does not create a private side queue; it sends the file into the same workspace capture flow used by the product’s broader ingest path, and the documents view watches that shared processing state. Mobile chat follows the same rule: it is tied to a workspace, refuses use outside an active member workspace, rejects archived or locked workspaces, applies daily and per-session limits, and consumes one chat credit before model work begins. That gives the owner a single mental model for what happens on mobile and what happens elsewhere in the product. If a document is captured on mobile, it is still workspace work. If AI answers on mobile, it still spends workspace credits. The boundary is not only cleaner for users; it also reduces ambiguity for the owner, because failures, limits, and credit use all land in the same workspace rules instead of branching into special mobile-only behavior.

The main qualifier is that this strength is about coherence, not completeness. The evidence shows a well-bounded companion surface, but not a full replacement for the web workspace. That is the right tradeoff for this chapter: mobile is solid because it keeps capture, chat, and workspace access aligned with the rest of the product, while leaving deeper bookkeeping work to the web side. For an owner, that is a practical design rather than a compromise hidden behind marketing language.