Schedule 2 — Service Description and Scope
Pocket Docket Ltd · company number NI742827 · registered in Northern Ireland · registered office 137 York Road, Belfast, BT15 3GZ
Why this document exists
This is the description of what you are buying. It forms part of the Terms of Service, and clause 2.3 of those terms points here.
It is written positively — what the Service does, what data it reads, what permissions it holds and what those permissions allow. It is deliberately not a list of things we are not liable for. If you want to know whether Pocket Docket does something, this is the document that answers it, and if something is not described here, it is not part of the Service.
1. The Service in one paragraph
Pocket Docket is a subscription to software that connects to your Xero organisation, computes a set of financial figures from your own accounting data, presents them on a live dashboard that refreshes hourly, and provides an AI assistant called Kipp that explains those figures in plain English and prepares drafts for you to review, approve and send yourself.
2. What the Service does
2.1 It reads your Xero organisation on a schedule
You connect one Xero organisation using Xero's own OAuth authorisation flow. From then on the Service pulls data from that organisation on an hourly schedule and stores a snapshot each time. The snapshots build a history, and the history is what makes trends possible — a single figure tells you where you are, a run of them tells you where you are going.
You can disconnect at any time, from inside Pocket Docket or from Xero's connected apps screen. Disconnecting stops the pulls immediately.
2.2 It computes figures in our own code
From each pull, the Service computes a defined set of named figures. These currently include:
| Figure | What it is |
|---|---|
| Cash position | Money in the bank across your bank accounts |
| Takings | Revenue for the period |
| Gross profit and gross margin % | Revenue less cost of sales, and the same as a percentage |
| Net profit | Profit after all costs in the period |
| Owed to you — total and count | Outstanding sales invoices, in value and number |
| Aged receivables | What you are owed, bucketed 0–30, 31–60, 61–90 and 90+ days |
| Aged payables | What you owe, bucketed the same way |
| Debtor days | How long, on average, it takes you to get paid |
| Creditor days | How long, on average, you take to pay |
| Customer concentration | Your top customers as a share of revenue |
| Period-on-period movement | What changed since the last period, and which line drove it |
Every one of these is calculated by a named function in our own code. Each function is unit-tested against fixtures with known answers. Each returns nothing rather than a wrong number when the input it needs is missing — a figure that cannot be computed is shown as unavailable, not estimated.
2.3 It presents those figures on a dashboard
The dashboard shows the current figures, how they have moved, sparkline trends over 30 days, 90 days and 12 months, and an ageing view of what you are owed. Where there is not enough history to draw a trend honestly, the dashboard says so instead of drawing one.
2.4 Kipp explains the figures
Kipp is an AI assistant built on a large language model supplied by Anthropic. Its job is to explain — to take a figure the software has already computed and put it into a sentence a business owner can act on. "Takings are £14,200 this month, up £1,840 on last month. What you are owed is up £600, because three invoices went past 30 days."
Kipp will also answer general questions about UK financial reporting, drawing on a knowledge base we have built and maintain, and citing the source it is relying on and the date that source was current.
2.5 Kipp prepares drafts
Kipp will prepare, at your request:
- a draft invoice — which can be created in your Xero organisation with
DRAFTstatus, using an account code you have chosen from your own active codes; and - a draft payment-chasing email — which is presented to you as text you can read, edit, and send yourself.
A draft is a proposal to you. It is not issued, not sent and not acted on until a person in your business has read it and approved it.
3. The Xero permissions we hold, and what each one allows
You see these on Xero's own consent screen when you connect. They are set out here so that you can read them somewhere other than at the moment you are clicking a button.
3.1 Identity and connection
| Permission | What it allows | Why we hold it |
|---|---|---|
openid, profile, email | Your name and email address from Xero | So you can sign up and sign in with Xero rather than typing in details Xero already holds |
offline_access | A refresh token, so the connection persists when you are not present | The Service syncs hourly on a schedule. Without this, the connection would break every time you closed the tab |
3.2 Read permissions
| Permission | What it allows | What it powers |
|---|---|---|
accounting.settings.read | Your chart of accounts, tax rates, organisation configuration and financial year | Presenting your own active account codes for you to pick from, and interpreting your financial year correctly. We never assume a default account code, which means we have to be able to read the real ones |
accounting.reports.profitandloss.read | Your profit and loss | Revenue, cost, margin and profit figures |
accounting.reports.aged.read | Aged receivables and aged payables | The "who owes me / who do I owe" views and the ageing buckets |
accounting.invoices.read | Your sales and purchase invoices | Invoice-level detail behind revenue analysis, top customers, and what is overdue |
accounting.banktransactions.read | Bank transactions | Your cash position |
accounting.reports.trialbalance.read, accounting.reports.balancesheet.read | Trial balance and balance sheet | Balance-sheet-derived figures and consistency checks on the computed figures |
accounting.contacts.read | Your contacts | Attributing revenue to named customers, and selecting a contact when preparing a draft invoice |
3.3 The one write permission
| Permission | What it allows | How we use it |
|---|---|---|
accounting.invoices | Creating and updating invoices in your Xero organisation | This is the only write permission we hold. We use it for one purpose: creating an invoice with DRAFT status when a person in your business asks for one |
We are going to be precise about this, because it matters and because you can check it.
accounting.invoicesis a read and write permission under Xero's granular scopes. It is not read-only.- Pocket Docket has never written anything to any customer's Xero organisation. Not an invoice, not a draft, not a note.
- When the draft-invoice feature is used, it will create invoices with
DRAFTstatus only. ADRAFTinvoice in Xero is not issued, is not owed by anyone, does not appear in your debtors, and does not go to your customer. Somebody in your business has to open it in Xero, check it and approve it before it becomes anything. - We are not telling you the software is technically incapable of writing to your Xero. It is not incapable. We are telling you what it does, what it has done, and what the controls are. A claim of technical impossibility would be something you could disprove in five minutes, and it is not true.
3.4 Permissions we deliberately do not hold
| Not requested | The consequence |
|---|---|
accounting.payments | We cannot record, apply or take a payment. We cannot move money. |
accounting.manualjournals | We cannot post a journal |
payroll.* | We cannot see or touch payroll or employee data |
bankfeeds | We are not a bank feed provider |
accounting.reports.taxreports.read | We do not read, prepare or file tax returns |
accounting.attachments, files.* | We cannot read or write attachments or files |
assets.*, projects.*, accounting.budgets.read | No fixed asset, project or budgeting functionality |
We ask for the minimum the product actually uses. If a permission is on that consent screen, there is a feature behind it.
4. How the AI part is built
This section describes the architecture, because the architecture is the answer to "what happens when it gets something wrong."
4.1 The model never does the arithmetic
Every financial figure shown to you, or referred to by Kipp, is computed by our own code before the model sees anything. The model is handed the finished figure and asked to explain it. It is not asked to add anything up, work out a percentage, or derive a number from underlying data.
This is a deliberate design decision and it is the most important one in the product. It means the highest-risk failure mode of a language model — a confidently wrong number — is converted into an ordinary software question with an ordinary software answer: named functions, unit tests, fixtures with known answers, and a null return rather than a guess.
It protects the figures. It does not protect the words. The explanations are model output, and clause 8 of the Terms of Service and section 5 below say what follows from that.
4.2 Retrieval before generation
When you ask a general question about UK financial reporting, the Service first searches a knowledge base we maintain, then hands the relevant passages to the model along with your question. The model answers from what it was given, and cites the source and the date that source was current.
The knowledge base is our own material, held per-tenant in the sense that it is the same reference corpus for everyone and contains no customer data. No customer's accounting data is ever added to it, and no customer's data is ever used to answer another customer's question.
4.3 The model is instructed to refuse rather than invent
Kipp's system instructions require it to decline where it cannot source a rate, a threshold, a deadline or a figure it can date-stamp, and to tell you to ask your accountant instead. The same instructions require it to be factual and neutral about money your business owes, and never to rank, prioritise or recommend deferral of your own liabilities.
That is an instruction to a model, not a guarantee about any particular answer. It reduces the frequency of a bad answer. It does not make one impossible.
4.4 What is sent where
When you ask Kipp a question, your question and the computed figures needed to answer it are sent to Anthropic to generate the reply. Anthropic is a sub-processor and is listed as one.
Your data is not used to train, fine-tune, adapt or enhance any machine-learning model — not by us and not by any provider we use. There is no cross-customer learning, no shared retrieval store built from customer data, and no benchmarking of one customer's numbers against another's.
4.5 The output notice
Every time Kipp produces written commentary, this notice appears with it, in the product, next to the output:
Written commentary is generated by an artificial intelligence language model. It may be incomplete, out of date or wrong. It is not reviewed by a person before it is shown to you.
5. The approval gate
Nothing the Service produces leaves your business, is issued to a third party, or moves any money, unless a person in your business has reviewed it and approved it.
In practice:
| What Kipp produces | What has to happen before it does anything |
|---|---|
| A draft invoice | It is created in Xero with DRAFT status. A person in your business opens it in Xero, checks it, and approves it there. Pocket Docket does not approve invoices and does not send them |
| A draft chasing email | It is shown to you as editable text. You read it, change it if you want to, and send it from your own email. Pocket Docket does not send it. There is no auto-send and there is no setting that turns one on |
| Written commentary | It is shown to you with the notice in section 4.5. It is not sent anywhere, published anywhere, or given to anyone else |
This is a technical control, not a policy. There is no configuration option that bypasses it, and there is no plan to build one. Approval events are logged with a timestamp and a record of what was approved.
Two consequences follow, and we state them because they are the point of the design:
- You are the review step. Clause 8.2 of the Terms of Service makes that an obligation you owe, because that is what it actually is.
- We do not make automated decisions about you or about your customers. The Service does not score, rank or grade your customers on whether they are likely to pay, and does not produce any decision that has a legal or similarly significant effect on anyone. Adding either would change that analysis, and both are on our list of things we will not build.
6. What the Service depends on
The Service is not self-contained and we would rather say so here than have you find out on a bad morning.
| Dependency | What it does | What happens if it stops |
|---|---|---|
| Xero | The source of every figure | The Service stops working. There is no Pocket Docket without Xero. Clause 21 of the Terms of Service covers this |
| Anthropic | The language model behind Kipp | Kipp stops answering. The dashboard and the computed figures keep working |
| Vercel | Hosting | The Service is unavailable |
| Supabase | The database that holds your snapshots and history | The Service is unavailable |
| Stripe | Billing | Payments are unavailable. Access to your dashboard is not affected |
| Resend | Emails from us are delayed |
Where a dependency fails, we degrade rather than break wherever we can. A failure in the AI layer should not take down your dashboard, and it is built so that it does not.
7. Availability
There is no service level agreement. We do not commit to an uptime percentage, a response time, support hours or service credits. Clause 13 of the Terms of Service says the same thing at more length, and says what we do commit to instead.
The Service syncs hourly. A sync that fails is retried; it does not silently overwrite the last good snapshot with nothing.
8. What is outside the Service
Stated here so the scope of what you are buying is closed at both ends. The Service does not include, and we do not supply:
- preparation, review or approval of statutory accounts, management accounts or any filing;
- any audit or assurance work;
- tax computation, tax advice, or any interaction with HMRC — the Service holds no HMRC connection and uses no agent credentials;
- bookkeeping, posting, coding or reconciliation of your ledger;
- any payment, collection or money-movement function;
- open banking or direct bank account access;
- credit scoring, credit reference data, or any assessment of anyone's creditworthiness;
- introductions to lenders, brokers or finance providers;
- advice on which of your liabilities to pay, defer, reschedule or compromise;
- multi-entity consolidation across more than one Xero organisation on a single subscription; and
- any integration with an accounting system other than Xero.
Some of these are product decisions we may revisit. Several of them are deliberate and permanent, because building them would put Pocket Docket inside a regulatory perimeter it has no business being in.
9. Changes to this Schedule
The Service changes as we build it. When it does, we update this Schedule and give it a new version number and date. Where a change materially reduces what the Service does, clause 13.5 of the Terms of Service applies and you may cancel and be refunded for the unused part of the month.
Version 1.0 · in force from 21 August 2026
© 2026 Pocket Docket Ltd · Registered in Northern Ireland, company number NI742827 · Registered office: 137 York Road, Belfast, BT15 3GZ · ICO registration ZC223982