Vendor approval workflows in Business Central: Design…

Engineering journal · Max Klein

Creating a vendor is not always enough in financial operations. Master data and payment details often require approval and a traceable audit trail.

Define the business rules

Separating vendor creation, review and payment authorization helps reduce risk. A vendor can be available for selected processes while payments remain blocked until bank details have been reviewed.

Use standard workflows first

Before developing custom logic, evaluate Business Central approval entries, workflow user groups and available workflow events. Extend the standard behavior only where business requirements demand it.

Important questions

Who can create vendors?
Which fields are mandatory before approval?
What happens when payment information changes?
How are rejections and comments recorded?
Can payment blocks be bypassed?

A sound approval design involves permissions, change history, approval state, payment blocks and clear user interaction.

1. Business objective: separate master-data entry from payment authorization

Four-eyes control means that the person entering a vendor or modifying sensitive bank details is not the sole approver of that change. Define who can create, who can approve and which state blocks payment. An approval indicator in the UI is insufficient unless downstream payment processing enforces the same state.

2. Design a meaningful state machine

A practical state model is Draft → Submitted → Approved / Rejected → Reapproval required. A vendor may also be usable for some operational activities while payment remains prohibited until bank verification is complete. Vendor approval and bank-account verification are distinct business facts, so avoid collapsing everything into one Boolean flag.

3. Review standard Business Central workflows first

Inspect approval user setup, workflow user groups, approval entries, and the workflow events and responses available in your actual BC version. Built-in events vary by version and localization. Implement custom AL logic only for rules that standard workflow setup cannot express reliably.

4. Assign approvers independently

Purchasing may create vendors while Finance checks bank information. Explicitly define the requesting and approving roles. Block self-approval where the internal policy requires it, including delegation and workflow group edge cases. Authorization must be enforced in the backend, not only in Role Center tiles.

5. Validate required fields at the appropriate stage

Depending on the organization, required data might include vendor name, postal address, country/region code, payment terms and bank account information. Reject placeholder values such as N/A where a real country code is mandatory. Different validation gates may apply at initial creation, submission for approval and release for payment.

6. AL illustration: encapsulate business checks

A dedicated review status can be useful in a project-specific extension. The following snippet illustrates a narrow rule only; it is not a complete implementation of approval or payment blocking.

enum 50150 "Vendor Review Status"
{
    Extensible = false;
    value(0; Draft) { Caption = 'Draft'; }
    value(1; Pending) { Caption = 'Pending'; }
    value(2; Approved) { Caption = 'Approved'; }
    value(3; Rejected) { Caption = 'Rejected'; }
}
codeunit 50151 "Vendor Review Rules"
{
    procedure RequireApproval(Vendor: Record Vendor)
    begin
        if Vendor.Blocked = Vendor.Blocked::All then
            Error('Vendor %1 is fully blocked.', Vendor."No.");
        // Production: also check independent vendor approval
        // and bank verification states.
    end;
}

The standard Vendor.Blocked field is not a replacement for every custom payment-control rule. A real solution must check the relevant status before generating or releasing payments.

7. Reapprove sensitive bank account changes

Changing the IBAN, bank-account holder or default bank account should invalidate the relevant bank verification. Record the previous and new details, mark payment readiness as requiring review, and open a new approval request. A page trigger alone is insufficient because bank data can also be changed through APIs, configuration imports and other background processes. Inspect every allowed data mutation path.

8. Audit trail and rejection comments

Record who requested the change, when it was submitted, who decided, the decision timestamp and the reason. Rejecting a request should normally return it for correction rather than delete the underlying evidence. Ensure standard users cannot silently change historical approvals.

9. Enforce the rule in payment processing

A visually approved vendor is not necessarily authorized for payment. Decide where payment journals, bank exports and automated payment tasks must verify bank readiness. Some processes may allow document posting while blocking payment. This distinction must be tested explicitly rather than relying on a generic vendor block.

10. End-to-end test matrix

Try to approve a vendor created by the same person.
Submit missing mandatory fields or an invalid country placeholder.
Approve a vendor and then change its IBAN.
Post an allowed transaction but attempt a prohibited payment.
Reject with a comment, correct the record and resubmit.
Change bank data via API and verify reapproval is required.
Test concurrent approvals, delegated approval and duplicate requests.

Conclusion: A genuine four-eyes workflow combines role separation, reliable change history and controls at the actual payment boundary. Details depend on the BC version and organization’s payment processes.

Vendor approval workflows in Business Central: Designing four-eyes control