Microsoft 365 Workflow Automation for Finance Teams

It means connecting four places the work already happens so that nothing gets retyped between them: Outlook, where documents and payment notifications arrive; Excel, where the team plans; OneDrive or SharePoint, where files are kept; and the ERP, which holds the ledger. The automation is the wiring between those four. Nobody has to learn a new system.

A typical brief looks like this. A Microsoft 365 tenant with OneDrive, Excel, a shared mailbox and PDF documents, a cloud ERP alongside it, and a short list of workflows: sync sales orders from the ERP into Excel on OneDrive, read bank payment notification emails and reconcile customer payments, generate outgoing delivery planning from sales-order delivery dates, extract and classify supplier invoice PDFs into purchase invoice entries, and automate monthly file creation, maintenance and archiving. Those five lines cover most of what a finance team still retypes by hand.

Operations buyers ask whether API and AI integration is inside a vendor's scope of expertise before they ask what it costs. That order is worth noticing if you are the one buying. The question you actually need answered is whether the vendor knows your systems by name, and a price list cannot tell you that. The wider set of processes is covered in our guide to AI back-office automation for SMEs.

Start at the mailbox, because that is where both the documents and the obligations arrive. The job of the intake step is to classify each message, save its attachments to a predictable location, create a record with a status, and leave the original message exactly where a person can still find it.

Use a shared mailbox rather than a personal one. A finance process that depends on one employee's inbox breaks the week they go on holiday, and it also makes the permission model impossible to reason about later. From that shared mailbox, a flow can route by sender, subject pattern and attachment type into a small number of categories: supplier invoice, bank notification, customer order, statement, everything else.

The intake step fails in ways worth designing for from day one. Invoices arrive in the message body rather than as an attachment. A single mail carries five PDFs of which two are invoices and three are delivery notes. Signature logos come through as attachments and look like documents. A colleague forwards the same invoice a second time, so deduplication has to run on document content and not on message id alone. Long forwarded threads contain three older invoices below the current one.

One rule holds through all of it: an unrecognised message is never silently discarded or marked handled. It goes to an exception folder with a reason attached, and someone owns that folder. An unwatched exception queue is worse than no automation, because the whole team now assumes the mail was processed, so settle how the review queue is designed and who works it before the first flow goes live.

Keep Excel, because it is the surface the finance team actually plans on, and automation that removes it loses its users in the first month. The workable pattern is a workbook stored on SharePoint or OneDrive, with machine-written data landing in structured tables through the Microsoft Graph API while human-edited columns stay untouched.

Four design decisions make that safe. Write into named Excel tables, never into fixed cell ranges, because somebody will insert a row and every hardcoded coordinate then points at the wrong data. Keep one sheet the machine owns and one sheet people edit, joined on a stable key such as the ERP order id. Write a last-sync timestamp into a visible cell, so anyone can see whether they are looking at this morning's data. Update the file through the API against the copy on SharePoint rather than a file sitting open on a desktop, and handle the case where the workbook is locked by a co-author.

Delivery planning is the workflow where this pays off fastest. Sales orders carry a requested delivery date; the planning sheet needs those dates grouped by week, by customer and by destination, refreshed whenever an order changes. Maintained by hand, that sheet goes stale the moment a delivery date moves. Maintained as a sync, it rebuilds on whatever schedule you set, and the planner keeps their own free-text columns for notes the ERP has no field for.

Say the limit out loud to the team: the workbook is a view, not the record. If a number is wrong in Excel, it gets corrected in the ERP and flows back, never patched in the sheet.

Decide the naming and folder rule once, then let a scheduled job apply it every month without exception. File organisation is the workflow teams postpone longest and the cheapest one to automate, because the rules are entirely deterministic and no model is needed anywhere in it.

A folder path that survives audit looks like year, then month, then document type, with the file itself named from fields that already exist: date, counterparty, document number. The payoff is addressability. Every other automation can then reach a document by constructing its path instead of searching for it, and a person asked for an old invoice opens it directly instead of hunting through libraries.

The monthly job itself has a small, fixed scope. Create next month's folder structure from a template before the month starts. Move closed documents from the working area into the archive. Generate an index of what was archived, with counts per document type. Apply the retention label the finance policy requires. Leave a short report in a channel or mailbox, so the close checklist has evidence behind the tick.

Two failure modes are worth pre-empting. First, moving a file breaks any link that pointed at its old location, so archive by moving and writing the new path back into the record that references it. Second, permissions inherited from a parent folder change when a file moves between libraries, which is how an archive quietly becomes readable by the whole company. Check the resulting permissions on a sample after the first run, not after the first complaint.

Use Power Automate for every step whose outcome is determined by the input, and add a model only where an incoming document has a layout nobody controls. That single line settles most of the build decisions.

Keep the model's job narrow: given this document, return these fields with a confidence per field. It never does arithmetic, and it never chooses which ledger entry the document belongs to. We apply the same rule to our own products. The AI-readiness checker on our homepage runs eight deterministic checks with no model-based scoring, so running it twice on the same site returns the same result. A finance process needs that property even more, because a workflow that returns a different answer on a second run cannot be reconciled or audited.

Power Automate has real limits worth knowing before you commit a critical path to it. Premium connectors sit behind their own licence. A flow created in a personal environment belongs to its creator, so ownership has to be transferred deliberately before that person leaves. Error handling is possible but awkward, source control is not how the platform is designed to be worked with, and throttling under load tends to surface as automatic retries and delay rather than as an obvious failure. Those limits are the Microsoft version of a judgment every automation project makes, the same one that decides where Zapier and Make stop paying off and a custom build starts. For the reading and matching, a small service with tests around it is easier to trust and easier to change.

Almost never. Exact Online, Merit and e-conomic all expose APIs, and the automation is built around the system you already run. Our blueprint for automating Exact Online with AI works through one of those integrations end to end, and the shape is much the same for the others. An ERP migration is a large project in its own right. It is rarely a prerequisite for automating around the ERP you have, and treating it as one delays the work that would have paid for itself first.

Three technical decisions carry most of the risk on the ERP side. Every write needs to be idempotent. Few accounting APIs offer an idempotency header of their own, so the workable pattern is to keep your own record of which source document has already produced which ERP entry and check it before posting. That check is what stops a retried request creating a second purchase invoice for the same PDF. Every write result needs to be stored back on the source record: the ERP document id lands next to the file path and the original message id, which is what lets you trace any ledger line back to the email it came from. And the first build runs against a sandbox or a test administration, with a small set of real documents, before anything touches live books.

Direction of truth has to be agreed in writing before the build starts. In practice the ERP owns master data and financial records, Microsoft 365 owns documents and planning, and the sync is one-way for each field. Two-way sync on the same field is where these projects generate their worst bugs, because two systems both think they were last correct and the newer timestamp wins for reasons nobody can reconstruct afterwards.

If your system genuinely has no API, the fallback is a file-based import against a scheduled export. It is slower to build and less pleasant to monitor, but it still removes the typing, which is the thing you are paying to remove.

Run the automation under its own service identity, with its own licence and only the permissions it needs. The most common governance mistake in Microsoft 365 automation is building flows inside a named employee's account, which means the process inherits that person's access to everything and stops the day their account is disabled.

Scope the access down deliberately. Grant the app rights to the specific SharePoint site it works in rather than to every site in the tenant. Give the mailbox connection access to the shared finance mailbox alone. Separate read from write where the platform allows it, and review the granted scopes when the workflow changes, because permissions accumulate and nobody ever removes one.

Credential expiry is the quiet killer. Client secrets and certificates expire, and when they do the flow fails overnight with an authentication error that nobody reads until somebody notices the missing entries. Put the expiry date in a shared calendar, alert on consecutive failures rather than on individual ones, and send the failure notice to a team address instead of the developer who set it up.

Governance also means naming the humans. One owner for the exception queue, with a response time. One approver for anything above a defined amount. One person who can pause the automation, and a documented way to do it that does not require a developer. Retention labels applied by policy, never by habit. An audit trail that records, per document, what arrived, what the system extracted, which rule decided, who confirmed and what was written to the ERP. An accountant will ask for exactly that, and the answer should be a screen you can open in front of them.

One well-defined workflow is typically a one to three week build, and the number of distinct exception types drives the effort far more than the number of documents per day. High volume from a handful of suppliers with stable layouts is a smaller job than low volume spread across many senders, each with its own layout.

Our published prices start at 290€ for an AI-readiness audit, which is credited against follow-up work, 990€ for implementing the fixes on an existing site, and from 3 999€ for a new build. Automation work is quoted per project, after we have seen real material. To quote a Microsoft 365 finance workflow we ask for a month of real emails including the messy ones, a copy of the workbook people actually use rather than the tidy version, the current folder tree, and read access to a test environment of the ERP.

Start with one workflow, measure the hours it returns, then extend to the next one. That is also the answer to "we are too small for this": prove it on one process before committing to five. Automation and AI visibility rest on the same requirement, which is facts a machine can read without guessing. That same requirement decides whether assistants name your company when a buyer asks for a recommendation. A typical business site we test in Estonia scores under 50 on our readiness checker. To see what a machine currently reads on yours, run the free readiness check against your own domain.