What a Charity Finance Audience Actually Asks About AI

On 7 July I ran a session for ACCA's Talking Series on what AI can genuinely do in a charity finance function today. Twelve minutes of it was a live demonstration on realistic charity data: a bank reconciliation from raw files to a drafted journal, a payroll journal split by cost centre and fund, and a management accounts pack. The remainder was meant to be Q&A.

Forty minutes was nowhere near enough. Twenty-two further questions arrived through the Q&A panel that we never reached, and ACCA has since passed them to me. I have answered every one in full, and the complete pack is available on request. What follows is the pattern underneath them.

It is worth saying what nobody asked. Nobody asked whether AI can read a bank statement, whether it can code a journal, or whether the demonstration was real. That argument appears to be over. What a room of charity finance professionals wanted to know was whether the output can be trusted, whether the data is safe, whether the thing can be shared with a team, and whether any of it is proportionate to a charity with four people in finance. Those are exactly the right questions, and they are considerably harder than the technical ones.

1. How much of this do I actually have to check?

A great deal at the start, and far less than you would expect once an automation has settled. That sequence is deliberate rather than accidental.

A new automation runs in parallel with the existing process for the first month or two, checked line by line. That is not wasted effort — it is how you find the edge cases in your own data: the odd fund, the supplier who pays in two instalments, the payroll cost centre that does not map cleanly. Once it is stable, the review takes minutes, because you are no longer re-performing the work. You are checking three things. Does it agree to a control total? Has it flagged everything it was unsure about? And does the narrative say what the numbers say?

A related question came from someone who had seen a different AI tool return numbers that were plainly wrong. In my experience most wrong numbers, in any tool, come from method rather than from the model. Ask a language model to read figures out of a document and total them in its head, and it is doing arithmetic probabilistically — it will occasionally be wrong in a way that looks entirely plausible. Change how you ask. Give it the source file. Make it calculate deterministically, by building the formula or running a script, rather than asserting a total. Then require it to reconcile to a control total you already know, and to show its workings.

2. Where does our data actually go?

Four of the twenty-two questions were about data protection, which tells you where the real barrier sits. The phrase "publicly available" runs two things together. The product is publicly available. Your data is not public, and it is not visible to other users.

What matters far more is the plan you are on. On the commercial plans — Team, Enterprise, or the API — a Data Processing Agreement is available, your inputs are not used to train the model by default, and retention is limited. On the consumer plans the position is different, and no Data Processing Agreement is offered. That single distinction is where most of the genuine risk sits, and it is why a member of staff quietly using a free personal login is a larger governance problem for your charity than the technology itself.

"Is it GDPR-compliant?" is not really a question about a product, either. Your charity is the data controller. The provider is a processor acting on your instructions, under contract. So compliance is something you establish, and the provider's job is to give you the terms and safeguards that let you establish it. Check four things: that your plan offers a Data Processing Agreement; that your data is excluded from model training by default; what mechanism covers international transfers; and what security assurance and sub-processor list the provider publishes. Then do your own part — a data protection impact assessment, a lawful basis, data minimisation, a retention position, a short AI use policy, and a line in your record of processing activities.

One member of the audience observed that Microsoft's Copilot is "quite safe" with sensitive data and asked how Claude compares. I would resist the framing. Safety here is a function of the plan and the configuration, not of the brand on the box. Commercial Copilot is a well-governed product, and if your charity already sits inside Microsoft 365 with licences you are paying for, that is a perfectly sound place to start. Ask any provider the same short list of questions. Focus on the tier, not the vendor.

3. Why Claude, and not something else?

Two people asked this, and it deserves an unglamorous answer. I use Claude because it works with files and folders the way a finance team works, because the work becomes a reusable skill rather than a clever prompt, and because the commercial plans carry a Data Processing Agreement and a not-for-profit rate that puts a governed footing within reach of a small charity.

But I do not claim it is superior in any permanent sense. These models leapfrog one another every few months, and anyone who tells you their favourite is definitively best is selling you something. The far larger determinant of output quality is the context you give the tool — your chart of accounts, your fund structure, your coding rules, your prior examples. That context transfers between tools. Get it right and most frontier models will do creditable work. Get it wrong and none of them will.

4. Does it post into our ledger? And could it replace the ledger?

Technically, increasingly yes. Anthropic's connectors directory now includes official Xero and Intuit QuickBooks connectors with read and write access, alongside Microsoft 365, SharePoint and OneDrive, so the tool can reach the bank statement or payroll file where it already sits. What those connectors are not, today, is an autonomous agent watching your ledger in the background; they operate inside a session that a person starts.

Whether you should post directly is a controls question, and my answer has not changed. Prepare, review, then post. Let the automation produce a fully formed journal — coded, balanced, with the workings and the exceptions attached — and let a qualified person approve it and post it, or import an approved file. That removes the re-keying, which is where the time actually goes, while preserving segregation of duties, an approval point, and an audit trail your auditor can follow.

Someone else asked whether Claude could replace accounting and payroll software altogether. No, and be wary of anyone who says otherwise. Your general ledger is your system of record. Your payroll software handles real-time information submissions, auto-enrolment and statutory payments. AI sits above those systems as an intelligence and assembly layer. That is a feature, not a limitation: it is why you can start without an ERP project, and why you can stop at any point without stranding your finance function.

5. Can a team actually share this?

This was the most technically precise question of the session, and it deserves a precise answer rather than a reassuring one. The observation is correct in substance. Cowork runs in the Claude desktop application, with web and mobile currently in beta and rolling out from the Max plan. Each person runs it under their own login, and Cowork projects — the task workspaces and their memory — live on that person's machine rather than syncing across a team.

What is shareable is the thing that matters, which is the work rather than the workspace. On Team and Enterprise plans an owner can stand up a private plugin marketplace and set each plugin to install automatically for everyone, to be available on request, or to be required. Skills can be provisioned centrally the same way, so a skill uploaded once appears in everyone's list. Organisation instructions, set once by an administrator, are followed in every conversation. And the inputs and outputs live in SharePoint or OneDrive, which your team already shares.

Picture what that means on a Tuesday in August. The colleague who runs the payroll journal and the variance analysis is on holiday. Neither skill lives on their laptop — each was written by them, submitted to your administrator, and provisioned centrally, so both already sit in your skills list. You enable them, point them at the payroll file in SharePoint, and run them. Same journal, same template, same control totals, because the rules travel with the skill rather than sitting in your colleague's head. What you don't inherit is their workspace, and that turns out to be a useful discipline: it forces the rules and the template into the skill itself rather than letting them accumulate quietly in one person's chat history.

One point belongs in your AI policy rather than your project plan. Anthropic's own guidance is that if you want to review skills before they reach everyone, you keep organisation-wide sharing switched off and ask people to submit them to an owner for provisioning. There is no built-in approval workflow, so that submission step is your approval workflow. In a charity I would run it exactly that way — one named person provisions, and the finance team's skills are scoped to the finance team.

The pattern, then, is shared skills, shared context, shared folders — and Cowork as each person's own cockpit. Which brings me to the question I was most pleased to receive: can the reports be saved as standard things to run, rather than continually running prompts? Yes. If the answer were "type a clever prompt each month", none of this would be worth your time. A skill is a folder holding a plain-language instruction and any supporting template. You write it once, and thereafter you invoke it by name. It is consistent, which is what makes the output auditable. It is editable by whoever owns it, so a change to the chart of accounts is a change to one line in a file rather than a rebuild. And it is yours — a folder of text files your team owns, which survives the person who created it.

6. We're small, and our reconciliations are fine. Is any of this for us?

That is fair, and I would rather answer it than defend the demonstration. I used a mid-sized charity's data because it shows the mechanics — restricted funds, cost centres, a payroll bureau file. If you are a small charity on Xero with clean, current reconciliations, then bank reconciliation is not your problem, and automating it would solve something you have already solved.

Your time goes somewhere else, and it is usually one of these: the variance commentary you write from scratch each quarter, the trustee reporting pack assembled by hand, the restricted fund schedule reconciled at year end, the audit or independent examination file, Gift Aid checks, and the SORP disclosures. Every one is repeatable, rules-based and data-heavy, which is to say every one is a strong candidate. And on "over the top" — the answer is not more report. It is the same report, in a fraction of the time, with the analysis already done before you sit down to write it. If your pack is right-sized, automate its production, not its length.

Restricted funds came up again from a different angle: could this produce external reports for institutional funders such as the UN and the EC, in their required formats? This is one of the strongest fits I know, and I say that having produced institutional donor reports across twenty-five country offices. Fixed formats, written eligibility rules, expenditure re-cut against the donor's budget lines, the same figures reshaped into four templates, deadlines that cluster. The requirement is simply that the rules exist in writing. Two cautions: donor reports carry personal data, so minimise what you send and check the grant agreement; and nothing goes to a funder without a person signing it.

7. What actually gets in the way?

People first, governance second, technology a distant third — and the second solves the first.

The technology is the easy part now. People are hard because the objection is rarely the one that gets voiced. What is said is "I'm not sure it's accurate". What is often meant is "I have done this reconciliation for eleven years and I am good at it, and I do not know what I am if a machine does it in four minutes". That deserves a real answer rather than a reassurance. The answer is to put the person in the review seat, visibly, and to make clear that the judgement is the job and always was.

Governance is where I would spend the effort, because it unlocks everything else. Trustees do not resist AI. They resist not knowing who approved it, what data it touched, and who is accountable when it goes wrong. Give them a one-page policy, a human review point and an audit trail, and the conversation moves from whether to how quickly.

Which leaves the question I found hardest, because the honest answer is uncomfortable. Do finance teams spend the time saved on higher-value work, or does it simply allow them to produce more reporting? It does whichever one you decide in advance — and if you do not decide, it becomes more reporting. So name the reinvestment before you automate anything. The business partnering, the reforecast, the restricted fund analysis, the controls testing. Write it down, tell your team, tell your board, and measure it crudely. The failure mode is not the technology producing more reporting. It is an organisation that quietly banks the saving, reduces the capacity, and then finds nobody has time for the analysis.

Where to start

Almost every question above resolves to the same three moves.

• Pick one process that follows the same rules every month, and write those rules down as though you were briefing a new joiner. That page is the real work — and it is finance work, not technical work.
• Run it against a month you have already closed, then in parallel for two months, checking everything and logging the exceptions.
• Take it to your board with three things: what it saved, what could go wrong, and a one-page AI use policy naming the approved tool, the data it may touch, and who signs off.

My thanks to ACCA, and to Astrid Spink in particular, for hosting the session and for passing on every question we did not have time to reach. The full written answers to all twenty-two run to a dozen pages, and I am happy to send the pack to anyone who would like it. If you would rather talk it through — including the parts where I have said be careful — I am always glad to.

Sources and verification: plan, product and connector facts were verified on 8 July 2026 against Anthropic's published product and help pages (claude.com, support.claude.com). These terms change frequently — confirm the current position before relying on it. On Cowork's platform availability, Anthropic's own help pages presently differ; web and mobile are in beta and rolling out from the Max plan, and this area of the product is changing quickly. Anthropic's published Data Processing Addendum relies on the ICO's International Data Transfer Addendum together with the EU Standard Contractual Clauses (verified 14 April 2026). Match rates, exception profiles and review times reflect my own practitioner experience rather than benchmark research. Nothing here is legal, tax or data protection advice.