Microsoft Fabric for Finance Teams: From Reporting Layer to Working Automation

Microsoft Fabric is Microsoft's unified data platform: one place where data from your ERP, CRM and operational systems lands (OneLake), gets cleaned and modelled in stages, and comes out queryable by anything that speaks SQL or Power BI. For a finance team, the practical translation is: one governed copy of your numbers, refreshed on a schedule, that every report reads from -- instead of a dozen exports with a dozen versions of the truth.

The standard structure is the medallion architecture, and the jargon is simpler than it sounds:

• Bronze -- raw data as it arrived from Business Central or your other systems, untouched.
• Silver -- cleaned and conformed: types fixed, duplicates handled, keys aligned.
• Gold -- business-ready tables shaped for consumption: open invoices, customer balances, aged receivables, revenue by entity.

The Gold layer exposes a SQL endpoint -- and that endpoint, not the dashboards, is where the underused value sits.

The typical Fabric deployment at a mid-market company follows a familiar arc: a data partner wires the ERP into the medallion layers, Power BI reports get built on Gold -- aged debtors, cash position, sales by region -- and the project is declared done. This is genuinely valuable. Month-end reporting gets faster, arguments about whose spreadsheet is right mostly disappear, and finance finally has a governed data estate.

But notice what dashboards do: they describe the state of the business to a human, who then goes off and does the work in other tools. The aged debtors report can tell you 47 accounts are overdue. Someone still has to decide whom to chase, write the emails, track the replies and remember the promises. The data platform is live; the work it points to is still manual.

That last mile is exactly where we've found the higher-leverage use of Fabric.

A Norwegian equipment rental group (~€30M revenue, Dynamics 365 Business Central, an existing Fabric deployment with Bronze/Silver/Gold layers) came to us with a collections problem: 1,080 open invoices, ~€7.6M outstanding, one person on AR. Their Fabric investment could already answer "who owes us what" perfectly. It just couldn't chase anyone.

So instead of bolting on an AR SaaS tool with its own copy of the data, we built the collections system on top of the Fabric layer they already had. Every morning, after their own pipeline refresh, a sync job reads open invoices from the Gold SQL endpoint. An AI agent then drafts the right chase email for each account -- staged to an aging-based cadence, in Norwegian -- classifies every inbound customer reply into one of twelve intents, and routes all of it through a human approval queue. A single agent run drafted 162 correctly-staged chase emails. The full build is in the case study, and the collections-specific detail in our Business Central AR guide.

The generalisable point isn't about collections. It's that the Gold layer is an operational interface, not just a reporting one. Anything your dashboards can see -- open invoices, unmatched payments, cost overruns, stalled approvals -- an automated system can see too, and act on.

The pattern we run in production has four rules, and they're all about keeping the warehouse trustworthy:

• Fabric stays read-only. The operational platform reads the Gold endpoint on a schedule; it never writes back. Agent-owned data -- tasks, drafts, conversation logs, approval decisions -- lands in the platform's own Azure PostgreSQL database. Your warehouse never gets polluted by application state.
• Sync after the refresh, not against it. The daily sync runs after the client's own pipeline completes, so the platform always works from the same numbers the dashboards show. Nothing is worse than automation and reporting disagreeing about the ledger.
• Act through Microsoft Graph, inside the tenant. Outbound email sends from the company's own shared mailbox via the Graph API -- threaded into existing conversations -- and inbound replies are polled from the same mailbox every ten minutes. The team signs in with Entra ID; the app runs on Azure Container Apps with scheduled jobs. Nothing leaves the Microsoft estate.
• Humans approve actions, not queries. Reading Gold is free; acting on it is gated. Every customer-facing email is a draft in an approval queue until a person releases it.

If you replace "chase email" with "supplier query", "rebate claim" or "cost-gap alert", the same four rules describe AP, job costing and controls automation on the same foundation. That broader pattern is what we cover under ERP finance automation.

None of this argues against dashboards; it argues against stopping at them. Two reporting-layer practices make the later automation step dramatically easier:

1. Shape Gold around finance objects, not report layouts. A Gold table like open_invoices with customer, amounts, due dates, dispute flags and payment references serves both a Power BI aged-debtors page and a collections agent. A table shaped like one specific report's rows serves only that report. If your Fabric partner is building Gold tables named after dashboard pages, push back.

2. Treat refresh reliability as a production SLA. A dashboard that's a day stale is an annoyance. An automation run against stale data sends a reminder for an invoice that was paid yesterday. The moment Gold feeds anything operational, pipeline monitoring and refresh timing stop being a BI nicety and become an operational dependency -- which is why our sync explicitly keys off the client's refresh completing.

No -- and it's worth being straight about that. Fabric was the right foundation for the rental group because they already had it; building on it meant weeks to production instead of a data project first. The same operational pattern works reading from Azure Synapse (our $11.8M collections build for a US insurance firm reads a Synapse view over Business Central), directly from an ERP's APIs, or from a plain SQL database.

The decision logic runs one way: don't deploy Fabric in order to automate -- but if Fabric or Synapse is already in place, build automation on its Gold layer rather than letting a SaaS tool make another copy of your ledger. You paid for a governed single source of truth; the automation should honour it.

If you have Fabric (or Synapse) in place and a finance process still running on exports and inboxes, three questions determine what to build first:

• Which Gold tables are already trustworthy? Automation should start where the data is already believed. If AR data is solid but cost data is contested, start with AR.
• Which process has the clearest rules? Cadences, thresholds and escalation paths that exist in writing (or can be written down in a workshop) automate cleanly. Judgment calls stay with people.
• Where does an hour saved compound? A one-person AR function chasing a €7.6M ledger was the perfect first target: the constraint was one human's hours, and every hour returned went straight into working capital via faster collections -- amplified in this case by receivables factoring.

These are the questions our AI readiness assessment works through against your actual estate. If your Fabric deployment currently powers dashboards and nothing else, tell us what's in your Gold layer -- we'll tell you what it could be running.