Your bank feed should still be useful after the person who built the spreadsheet goes on holiday. That starts with a clear workbook: one place for incoming rows, one place for decisions, and a short note explaining how the two connect.
For a UK household, that can mean a shared spending review. For a small business, it can mean a weekly cash meeting that does not begin with “which copy of the file is current?”
This guide designs that workbook around BankSync's existing Excel integration. The goal is a dependable input for your own reporting, with a simple first-run acceptance check.
Product availability and documentation reviewed on 1 November 2026. Workbook names and examples below are suggested designs.
Give each worksheet one job
| Suggested worksheet | Purpose | Who changes it |
|---|---|---|
| Transactions | Incoming bank records with stable columns | Feed owner controls mapping |
| Review | Categories, exceptions and approved adjustments | Household or finance reviewer |
| Summary | Cash movement, spending and trend reports | Report owner |
| Read me | Scope, sign convention, cutover date and owner | Workbook maintainer |
Start with a clearly owned cloud workbook
The Excel integration documentation requires a workbook in OneDrive and the Microsoft account that can access it. A file saved only on your laptop is not the destination for this workflow. Work accounts can require administrator approval.
Choose a recognisable filename, such as “Household cash review 2026” or “Studio weekly cash”. Avoid relying on names such as “final”, “final2” and “latest”. Record the actual workbook link in your operating notes.
Decide who owns the connection and who reviews the numbers. For a business, use your organisation's approved account and access process. A shared working arrangement should not depend on someone sharing their Microsoft password.
Connect and verify the destination
Prepare the workbook
Save it in OneDrive and create a clearly named incoming-transactions worksheet.
Connect Microsoft Excel
In BankSync Integrations, add Microsoft Excel and complete the authorisation flow with the correct Microsoft account.
Choose the destination
In the feed, select the Excel connection, then the workbook and worksheet.
Map a small useful schema
Keep the source date, amount, account, currency and description; include status and identity fields where available.
Run and compare
Open the selected workbook and compare a sample of delivered rows with the source account.
Protect the boundary between input and analysis
A common spreadsheet problem begins when a report is placed directly beneath a growing transaction list. New rows eventually collide with totals, notes or manual calculations. Separate worksheets make that boundary easier to maintain.
Keep a stable set of source columns. Put your own explanations, adjustments and category rules in a clearly identified review structure. If you add calculated columns alongside incoming data, test what happens when the next batch arrives; do not assume your formulas fill into every new row.
Build reports from an explicit range or Excel table that you maintain. After a sync, check that the report includes the final incoming row. A worksheet can contain the correct records while a summary still points to an old fixed range.
For a shared workbook, write down which fields are source facts and which are editorial decisions. “Amount” and “review category” have different jobs. Changing a category should not quietly change the original bank amount.
A first-run acceptance test
| Check | Illustrative evidence | Pass condition |
|---|---|---|
| File identity | The chosen workbook opens from its saved link | It is the file the team actually uses |
| Account scope | One known payment from each included account | Expected accounts are represented |
| Sign convention | An outgoing purchase and incoming payment | Signs match the report's assumptions |
| Data types | A date filter and numeric sum work | Dates and amounts behave as expected |
| Report range | Newest delivered row appears in review | No records fall outside the summary source |
| Routine sync | Run normally after the first delivery | No unexplained duplicate set appears |
Make the setup recoverable
Write a five-line handover note: purpose, accounts included, destination, feed owner and last reconciliation date. Add any deliberate exclusions, such as pending transactions or an account that belongs to another person.
If someone changes the destination worksheet or field mapping, treat it as a small release. Save the previous configuration in your notes, run a bounded check and inspect the report before relying on the next totals.
If Microsoft access expires, follow the documented reconnect flow. BankSync says this refresh preserves existing feed configuration and written rows. That is different from creating a second feed pointed at the same worksheet.
A sensible recovery test is “can another authorised maintainer find the owning feed and understand these columns?” It does not require sharing credentials or rebuilding the entire spreadsheet.
Understand what a working feed does not prove
An automated delivery is one part of the workflow. It does not establish that a bank supplied all historical records, that a category is correct, or that a forecast payment will happen.
For UK connections, consult the UK bank guide for account availability, initial history and pending-status behaviour. For delivery semantics, read transaction syncing.
The add-in availability notice is the source for the release caveat above. Recheck that page before changing your onboarding instructions when the add-in becomes available.