Approval Workflows and Document Handling in Business Central

There is a moment in almost every Business Central implementation where the conversation stops being about accounting and starts being about control. Someone from finance asks the obvious question: what stops a junior buyer from raising and posting a fifty thousand dirham purchase order without anyone senior seeing it? The answer, if the system is set up properly, is the workflow and approvals engine. Get that engine configured with judgement and you have a system that enforces policy quietly in the background, keeps a clean audit trail, and still lets people do their jobs. Get it wrong and you build a bureaucracy in software, a maze of approvals that people learn to route around, which is worse than having no controls at all because it gives the illusion of governance while training everyone to bypass it.

The message up front: approval workflow in Business Central is not about adding as many checkpoints as possible. It is about placing the right checkpoint at the right value threshold on the right document type, backed by a clean record of who approved what and the evidence attached to prove it. Good governance is the smallest set of controls that satisfies the risk, not the largest set the software will allow.

1. Why workflow and controls matter in an ERP

A finance system without controls is just a very expensive ledger. It records what happened, but it does nothing to shape what is allowed to happen. The whole point of moving from spreadsheets and email approvals to a system like Business Central is that the rules stop living in people's heads and start living in the platform, enforced consistently whether the approver is at their desk, on leave, or left the company last month.

Controls exist to answer a small set of questions that every auditor, every CFO, and eventually every regulator will ask. Who authorised this spend? Was the person who approved it actually allowed to approve at that value? Is there evidence that the goods or service were genuinely received and the invoice matches the order? Can we prove none of this was altered after the fact? In a properly governed Business Central environment, the workflow engine, the approval setup, and the document attachment features together answer all of those questions without anyone having to reconstruct the story from an inbox.

This matters more, not less, as an organisation grows. In a five-person company the controls live in trust and proximity: everyone sees everything, and the owner signs the cheques. At fifty people, and certainly at five hundred, that visibility evaporates. Segregation of duties, the principle that the person who raises a transaction should not be the same person who approves and pays it, becomes both a genuine fraud control and a formal audit requirement. Workflow is how you encode segregation of duties into the system so it is enforced automatically rather than depending on someone remembering the policy. For a broader view of where these controls sit inside the wider product, the complete guide to Business Central features maps how the finance, purchasing and governance modules connect.

2. The Business Central workflow engine: how it is structured

Business Central ships with a built-in workflow engine, and understanding how it is structured is the difference between configuring it deliberately and copying a template you do not really understand. The engine is built on a simple but powerful model: workflows are made of steps, and each step has three parts. There is an event that triggers the step, a condition that filters when it applies, and a response that the system performs when the event fires and the condition is met. Think of it as: when this happens, and these criteria are true, do this.

A typical approval workflow reads almost like a sentence when you lay the steps out. When a purchase order is submitted for approval, and the amount is above the approver's limit, then create an approval request and set the document status to pending approval. When that request is approved, then release the document. When it is rejected, then send it back to the originator. Each of those clauses is a workflow step, and Business Central chains them together into a running process that manages the document through its lifecycle.

Microsoft provides a library of predefined workflow templates for the common scenarios, purchase document approval, sales document approval, journal approval, customer and vendor record approval, and more. In most implementations you do not build a workflow from a blank sheet; you copy the relevant template and adjust the conditions and responses to match your policy. That template library is deliberately practical: it encodes the patterns that the vast majority of businesses actually need, so the configuration work becomes tuning rather than invention.

Underneath the workflows sit two supporting concepts worth naming. Workflow user groups let you define reusable sets of approvers and their sequence, so a workflow can reference a group rather than hard-coding individuals. Approval user setup, which we come to shortly, defines each user's approver, their spending limits, and their substitute. The workflow engine reads from both of these when it decides who a request should go to and whether it needs to escalate up a chain. Keeping the routing logic in the user setup rather than baked into the workflow steps is what makes the whole thing maintainable when people change roles.

3. Approval workflows in practice

The abstract engine becomes concrete the moment you apply it to real document types, and the four that matter most in day-to-day operation are purchase documents, sales documents, payment journals, and general journals. Each carries a different risk and therefore deserves a different approval posture.

Purchase documents are where most organisations start, because this is where money leaves the business and where the fraud and error risk is highest. Purchase quotes, purchase orders, and purchase invoices can each be routed through approval. The most common design routes the purchase order for approval before it is sent to the supplier, so that commitment to spend is authorised before the supplier is ever contacted. The submitter clicks to send for approval, the document locks into a pending state that cannot be posted, and it only releases once the required approvers have signed off. This is the single most valuable control in most Business Central deployments, and it connects directly to the wider procurement discipline covered in the purchasing management guide.

Sales documents matter for a different reason. Here the risk is not fraudulent spend but unauthorised commercial terms: a salesperson granting a discount beyond policy, extending credit to a customer who should be on hold, or committing to pricing that erodes margin. Sales order and sales quote approval lets you require sign-off when a discount exceeds a threshold or an order pushes a customer over their credit limit. It is a lighter touch than purchasing in most businesses, but on high-value or discount-sensitive deals it protects margin the same way purchase approval protects cash.

Payment journals are the highest-stakes control point of all, because this is the moment cash actually moves to a bank. Approving the payment journal before it is posted and exported to the bank means a second person confirms the payment run: the right vendors, the right amounts, no duplicates, no unexpected additions. In a well-governed environment the person who prepares the payment run is never the person who approves it, and the payment journal workflow is what enforces that separation in the system rather than on paper.

General journals are the quiet risk. Manual journal entries can move money between accounts, write off balances, and adjust the ledger in ways that bypass the normal transaction flow. Because they are flexible, they are also the classic vehicle for both honest error and deliberate manipulation. Requiring approval on general journals above a materiality threshold, particularly for entries that touch sensitive accounts, closes a gap that many organisations leave wide open because journals feel like an internal, low-visibility activity. They are exactly the entries an auditor scrutinises first.

The practitioner's sequencing: do not switch on approval for every document type at once. Start with purchase orders, because that is where the risk-to-effort ratio is best and where users most readily accept the discipline. Prove the workflow works and people trust it, then extend to payment journals, then sales and general journals as the appetite and the maturity grow. A phased rollout earns adoption; a big-bang rollout breeds resentment and workarounds.

4. Approval user setup, approval limits and hierarchies

The workflow engine decides that a document needs approval; the approval user setup decides who it goes to and how far up the chain it must climb. This is configured per user, and getting it right is where governance either becomes robust or becomes a house of cards. Each user in the approval setup has a designated approver, which is the person their requests escalate to. That single relationship, chained across many users, is what forms the approval hierarchy.

Alongside the approver, each user carries approval limits, the maximum value they are authorised to approve. Business Central distinguishes a few limit types. There is an amount approval limit for spend, and there can be separate limits for specific contexts such as requests and credit limits, depending on the workflow. A user can also be flagged as having unlimited approval authority, which is how you designate the top of the chain, typically a finance director or managing director whose sign-off ends the escalation.

The hierarchy works by comparison. When a document is submitted, the engine checks the amount against the submitter's own limit and against their approver's limit. If the amount exceeds the first approver's authority, the request escalates automatically to that approver's approver, and so on up the chain until it reaches someone whose limit covers the value or who has unlimited authority. This is the mechanism that lets you express a real policy such as: line managers approve up to ten thousand, department heads up to fifty thousand, the finance director above that. You are not building those tiers as workflow steps; you are expressing them as limits on the user records, and the engine walks the chain for you.

Two configuration details save a great deal of pain later. The first is the substitute approver. Every approver needs a defined substitute so that when the primary is on leave, requests do not sit stranded in a queue while a purchase order goes stale. Business Central supports substitution, and configuring it up front is far easier than diagnosing a stuck approval three weeks into go-live. The second is the approval administrator, a role that can delegate and manage requests centrally, which is essential for handling the inevitable edge cases where the normal chain breaks down.

The honest limitation: the approval hierarchy in Business Central is fundamentally a chain of single approvers walking up by value. It handles vertical escalation elegantly. What it does not do natively, in its simplest form, is complex parallel or matrix approvals, for example requiring both a budget owner and a technical owner to approve the same document independently, or routing by cost centre and category simultaneously. Those richer patterns are exactly where Power Automate comes in, which we get to below. Trying to force a genuinely matrixed approval policy through the native chain alone leads to convoluted, fragile setups. Know where the built-in model ends.

5. Notifications and the approver experience

A control that people do not notice is a control that does not work, so how approvers are told about pending requests, and how easily they can act, determines whether the whole workflow is a help or a hindrance. Business Central gives approvers several routes to the same decision, and understanding them lets you design for the way your people actually work.

Inside the application, approvers see their pending requests directly. The Requests to Approve page collects everything waiting on them in one list, and each user's role centre can surface a cue showing the count of outstanding approvals so it is visible the moment they log in. From there, approving or rejecting is a click, and the approver can drill into the underlying document to see exactly what they are signing off before they decide. This in-product experience is the backbone: it keeps the decision, the evidence, and the audit trail in one place.

Notifications extend that reach beyond the moment someone happens to be logged in. Business Central can notify approvers of pending requests, and the notification behaviour is configurable per user so you can tune how and when people are told. The genuinely modern approver experience, though, comes from the integration with Outlook and Teams. Because Business Central lives in the Microsoft ecosystem, approval notifications can reach people where they already spend their day, in their email and in their chat, rather than requiring them to remember to open a separate application. An approver can receive the request, see the key details, and act without a context switch.

The design principle I hold to here is that friction is the enemy of compliance. If approving a routine purchase order takes six clicks and a login, busy managers will batch-approve without looking, or worse, pressure the requester to find a way around the workflow entirely. The more the approval lands in the approver's normal flow of work, with enough context to make a real decision quickly, the more the control is genuinely exercised rather than rubber-stamped. Good governance respects the approver's time as much as it respects the auditor's requirements.

6. Document attachments: attaching and linking files to records

Approvals govern the decision; document handling governs the evidence. A purchase order approved without the supporting quote attached, an invoice posted without the delivery note linked, a customer set up without the signed contract on file, all of these leave the record technically complete but evidentially thin. Business Central provides several complementary ways to attach and link files to records, and using them consistently is what makes a record audit-ready rather than merely posted.

The most direct mechanism is the attachment. Most document and card pages in Business Central expose an attachments feature, usually surfaced through the FactBox on the side of the page, where you can attach a file directly to that specific record. A scanned supplier quote attached to the purchase order, a signed delivery note attached to the posted receipt, a contract attached to the vendor card. The file is stored against the record and travels with it, so anyone who opens the document later, including an auditor, finds the evidence in the same place as the transaction. This is a considerable improvement over the old world where the paperwork lived in a shared drive or a filing cabinet with only a loose reference connecting it to the ledger entry.

Alongside attachments, Business Central offers links and notes. A link records a reference to something external, a URL to a document held in SharePoint or another system, which is useful when you deliberately keep the master copy elsewhere and only want the record to point to it. A note is a free-text annotation on the record, handy for the human context that does not belong in a structured field: why an exception was granted, what a supplier promised on a call, a reminder for the next person to touch the record. Together, attachments, links and notes cover the spectrum from embedded evidence to external reference to internal commentary.

There is also a distinction worth drawing between attachments that stay internal and documents you want to send. Incoming document records, which we cover next, are specifically designed for the inbound evidence around a transaction, most importantly supplier invoices, and they carry richer capability than a plain attachment because they are meant to feed the transaction itself, not just sit beside it.

A caution on storage and habit: the attachment features are only as valuable as the discipline behind them. If half the team attaches supporting documents and half does not, the records are inconsistently evidenced and an auditor will find the gaps. The technical capability is the easy part; the standard operating procedure that says a purchase order is not submitted for approval until the quote is attached is the part that actually delivers governance. Configure the capability, then enforce the habit through policy and, where it matters, through the workflow itself.

7. Incoming documents and capturing supplier invoices

The single highest-volume piece of inbound paper in most finance functions is the supplier invoice, and Business Central has a dedicated feature set for capturing it: incoming documents. An incoming document is a record that represents an inbound file, typically a supplier invoice or credit memo, before and during its conversion into a posted transaction. Rather than someone reading a PDF and keying the invoice by hand into a purchase invoice, the incoming document becomes the anchor: the file is registered, processed, and turned into the purchase document, with the original file linked to the resulting entry for the whole audit trail.

The capability that makes this genuinely time-saving is OCR, optical character recognition. Business Central integrates with an OCR service so that an emailed or uploaded invoice can be read automatically, the key fields, vendor, invoice number, date, amounts, and lines, extracted, and a draft purchase invoice created for a human to review and approve rather than type from scratch. The person's job shifts from data entry to verification, which is faster, less error-prone, and frankly a better use of a finance professional's time. The OCR is not magic; it needs review, and it improves as it learns supplier layouts, but it removes the drudgery of manual keying on high-volume, repetitive invoices.

This inbound capture story is now being reshaped by electronic invoicing mandates. As tax authorities move to structured e-invoicing, the invoice increasingly arrives not as a PDF to be read by OCR but as a structured electronic document that Business Central can ingest directly, with the fields already machine-readable and validated. That is a cleaner and more reliable path than OCR because there is no interpretation step: the data is structured at source. For organisations operating in the UAE, this is a live and near-term concern, and I have written a dedicated guide on it in UAE e-invoicing and Dynamics 365 Business Central integration. The direction of travel is clear: manual keying gives way to OCR-assisted capture, and OCR-assisted capture gives way to structured e-invoice ingestion, with each step reducing effort and error while strengthening the audit trail.

Whichever capture route applies, the governance payoff is the same. The original supplier document is linked to the transaction it created, the invoice is matched against the purchase order and receipt before it is approved and posted, and the whole chain from order to receipt to invoice to payment is evidenced inside one system. That is the closed loop that three-way matching depends on, and incoming documents are the mechanism that brings the supplier's paper into the loop cleanly.

8. Power Automate as the modern extension of built-in workflow

The native workflow engine is capable and, for the common approval patterns, entirely sufficient. But it has boundaries, and the moment a governance requirement pushes past those boundaries, the modern answer is Power Automate, Microsoft's low-code automation platform, which integrates deeply with Business Central. Understanding the division of labour between the two is one of the more valuable pieces of judgement in a modern implementation.

The built-in engine is best when the requirement is a straightforward value-based approval chain on a standard document type, entirely inside Business Central, with no dependency on other systems. It is fast to configure, it needs no additional licensing beyond Business Central itself in the common case, and it keeps the whole process in one place. For a large share of organisations, the native workflows do everything they need and reaching for Power Automate would be over-engineering.

Power Automate earns its place when the requirement outgrows that model. Genuinely parallel approvals, where two different roles must approve independently. Conditional routing on criteria the native engine does not evaluate cleanly, such as project, cost centre and category simultaneously. Approvals that need to reach into or pull from another system, sending a Teams adaptive card, logging to a separate register, checking a value in a different application before deciding. Long-running processes with reminders, escalations on timeout, and rich notifications. All of these are Power Automate's natural territory, and because it triggers on Business Central events and acts through the Business Central connector, it extends the platform rather than replacing it.

The way I frame the choice for clients is that native workflow is the default and Power Automate is the deliberate extension. Start with the built-in engine because it is simpler, cheaper, and closer to the data. Move a specific approval to Power Automate when, and only when, that approval has a concrete requirement the native engine cannot meet well. Do not rebuild simple purchase order approval in Power Automate just because it is the newer, shinier tool; that adds licensing cost, a second place to maintain logic, and an external dependency, all for no governance gain. This sits within the broader question of how Business Central connects to the rest of the Microsoft platform, which I cover in depth in the Business Central and the Microsoft ecosystem guide. The Power Platform relationship is a genuine strategic advantage of Business Central, and approval automation is one of the clearest places it pays off, provided you deploy it where it adds value rather than everywhere it could reach.

9. Designing a governance and approvals model

Configuring the features is the easy half. Designing the governance model they enforce is the half that separates an implementation that protects the business from one that merely annoys it. Over years of doing this, I have settled on a framework that keeps the model both defensible to an auditor and tolerable to the people living inside it.

Start from risk, not from documents. The instinct is to go through each document type and ask what approval it should have. The better starting point is to ask where the real risk sits: where money leaves the business, where terms are committed, where the ledger can be manipulated. Purchase orders and payment journals carry the most cash risk; sales discounts carry margin risk; general journals carry manipulation risk. Put the strongest controls where the risk is greatest and the lightest controls, or none, where it is trivial. A control that guards nothing important is pure friction.

Set thresholds that mean something. The value at which approval kicks in should reflect materiality, not habit. If everything above one dirham needs approval, you have made approval meaningless because it is constant and unconsidered. Set thresholds so that routine low-value transactions flow without ceremony and only genuinely material commitments trigger a human decision. The right number is a business judgement about what value is worth a manager's attention, and it is usually higher than the nervous first instinct suggests.

Encode segregation of duties explicitly. The person who creates a transaction should not be able to approve it, and the person who approves a payment should not be the one who prepared it. Use the approval hierarchy and the payment journal workflow to make these separations structural rather than trusting people to observe them. This is both the strongest fraud control available and the thing auditors test most directly.

Design the fallback before go-live. Every approval chain will, at some point, hit an approver on leave, an approver who has left, or a document that falls outside the normal path. Configure substitutes, define an approval administrator who can intervene, and agree the escalation for genuine exceptions before they happen. The absence of a designed fallback is what causes documents to sit stuck for days, which in turn is what drives people to demand the whole control be switched off.

Attach the evidence to the record, not the inbox. Make it standard that the supporting document, the quote, the contract, the delivery note, lives on the Business Central record via attachments or incoming documents, so the evidence and the transaction are never separated. A governance model where the approvals are tight but the evidence is scattered across email and shared drives fails the moment someone has to prove a specific transaction was legitimate.

Review the model periodically. Limits set at go-live drift out of date as the business grows, roles change, and inflation moves the value of a threshold. A governance model is not a one-time configuration; it is a living policy that should be reviewed at least annually against how the business actually operates now. The best-run environments treat the approval limits table as something finance owns and revisits, not something IT set once and forgot.

10. Common workflow mistakes and how to avoid over-engineering

The failure patterns in Business Central approval implementations are remarkably consistent, and almost all of them come from the same root error: treating more control as automatically better control. The mistakes I see repeatedly:

• Too many approval layers. A purchase order that must climb through four approvers before a supplier can be contacted does not add four times the assurance; it adds four times the delay and trains everyone to see approval as an obstacle. Beyond two, occasionally three, meaningful layers, each additional approver is usually rubber-stamping, which is worse than no control because it manufactures the appearance of scrutiny without the substance.
• Thresholds set too low. When trivial transactions trigger approval, approvers are flooded, stop reading, and batch-approve on reflex. The control that fires on everything is the control that guards nothing. Set thresholds high enough that an approval genuinely warrants a moment's attention.
• No substitute approvers. The most common cause of a stalled process is a single approver on leave with no configured substitute. Documents pile up, deadlines slip, and someone eventually asks to disable the workflow. A designed substitution path prevents the whole failure.
• Approvals with no evidence attached. Signing off a purchase order or invoice with no supporting document linked means the approver is approving a number, not a decision, and the record fails the audit later. Tie the evidence to the workflow so the document cannot advance without it where it matters.
• Rebuilding simple things in Power Automate. Reaching for the more powerful tool when the native engine would do adds cost, a second maintenance surface, and an external dependency for no governance benefit. Use Power Automate for what only Power Automate can do, and leave straightforward approvals in the built-in engine.
• Configuring once and never reviewing. Limits and hierarchies that made sense at go-live quietly become wrong as the business changes, leaving either gaps where control has eroded or friction where thresholds no longer match reality. Schedule the review.

The thread running through all of these is the tension between control and usability, and the practitioner's job is to hold both. A system that is all control and no usability gets bypassed; a system that is all usability and no control gets exploited. The right answer is almost always fewer, better-placed controls than the software will let you build, each one guarding something that genuinely matters, each one designed so that a busy person can satisfy it quickly. Over-engineering approvals is not a sign of rigour. It is a sign that the risk was never properly analysed, so every possible checkpoint was added as insurance against thinking hard about which ones actually count.

Final thoughts

Approval workflows and document handling are the features that turn Business Central from a system that records the business into a system that governs it. The workflow engine enforces who is allowed to authorise what, the approval user setup encodes the hierarchy and the limits, the notification and approver experience determines whether the control is genuinely exercised or merely tolerated, and the attachment and incoming document features keep the evidence bound to the transaction so the whole story survives an audit. Power Automate extends the model where the native engine reaches its limits, and used with judgement it adds real capability without replacing what already works.

But every one of these features is a tool, not a policy. The tool does what you tell it, and if you tell it to demand four approvals on a five hundred dirham stationery order, it will, and your people will hate it and route around it. The skill is not in switching features on; it is in the governance model behind them, the deliberate placing of the right control at the right value on the right document, with a designed fallback and the evidence attached, reviewed as the business changes. Build that model with restraint and Business Central gives you governance that is quiet, consistent and genuinely protective. Build it as a maze of checkpoints and you get the illusion of control at the cost of the thing you were trying to protect: a business that can actually get its work done.

Related reading: The complete guide to Business Central features, Purchasing management in Business Central, Business Central and the Microsoft ecosystem, UAE e-invoicing and Business Central integration.