Approvals for Accounting Documents
Every accounting team has a version of the same rule: somebody senior signs off before money moves. Because REDA Financials is built natively on Salesforce, you don't buy or bolt on an approval engine — the platform's own Approval Processes drive sign-off on accounting documents, with the routing, delegation, email notifications, and audit history that the rest of your company already uses. This article explains how the two halves meet: what REDA Financials enforces, and what Salesforce lets you design.
The posting gate
Five REDA Financials documents carry an Approval Status field, and it acts as a hard gate: the document can only move from Draft to Posted when Approval Status is Approved or Not Required. Nothing reaches your ledger while a sign-off is outstanding.
| Document | Default Approval Status | What that means day one |
|---|---|---|
| Purchase Order | Not Required | Posts immediately until you switch approvals on |
| Purchase Invoice (Invoice & Expense types) | Not Required | Posts immediately until you switch approvals on |
| Purchase Invoice (Vendor Memo type) | Pending | Requires approval before posting, out of the box — vendor credits are a classic fraud vector, so the cautious default is deliberate |
| Sales Invoice | Not Required | Posts immediately until you switch approvals on |
| Budget | Not Required | Posts immediately until you switch approvals on |
| Budget Entry | Not Required | Posts immediately — but once approved, an entry freezes (only its Approval Status can change), and reopening resets it to Pending |
Try to post ahead of the sign-off and the system stops you with the exact reason:
| The message | Where you see it |
|---|---|
| "Purchase Order requires approval before posting. Approval Status must be Approved or Not Required." | Posting a PO that is Pending or Rejected |
| "This purchase invoice requires approval before posting. Approval Status must be Approved or Not Required." | Posting a purchase invoice — including a Vendor Memo still at its Pending default |
| "This document requires approval before posting. Approval Status must be Approved or Not Required." | Posting a sales invoice awaiting sign-off |
| "Budget entry reopened for editing. Approval status reset to Pending." | Reopening an approved budget entry — the sign-off must be earned again |
Designing the approval itself
REDA Financials enforces the gate; Salesforce Approval Processes supply the workflow. An administrator builds the process once in Setup — no code — and decides:
| Design choice | Accounting examples |
|---|---|
| Entry criteria — which documents need sign-off | Purchase invoices over 10,000 · every vendor memo · budgets for the new fiscal year |
| Approval steps — who signs, in what order | Manager first, then the controller for large amounts; parallel sign-off from two department heads |
| Field updates — what happens on approve / reject | Set Approval Status to Approved on final approval; to Rejected on rejection — this is the wiring that opens or keeps the posting gate closed |
| Notifications — who hears about it | Email the requester on rejection with the approver's comments; alert the AP manager when a document waits more than two days |
Once a process is active, the standard Submit for Approval button appears on the document, approvers work from email, the approvals list, or their phone, and every decision is recorded in the document's approval history — who, when, and any comments, permanently.
A worked example: Meridian's vendor-memo rule
Meridian Properties Group wants every vendor credit reviewed by the AP manager before it can offset a bill. The setup takes four decisions:
Nothing to configure on the document
Vendor Memos already default to Approval Status Pending — the gate is closed from the moment the memo is saved.
Build the process
An administrator creates an Approval Process on the purchase invoice for Vendor Memo documents, with one step: the AP manager approves.
Wire the field updates
Final approval sets Approval Status to Approved; rejection sets Rejected. That's the entire integration — no code on either side.
Work the flow
The clerk clicks Submit for Approval on MVM001001 (the $300 Apex Facilities credit). The AP manager approves from email. Approval Status flips to Approved, and posting now succeeds — with the sign-off in the record's history for the auditors.
Where approval lives elsewhere in the system
| Area | The control |
|---|---|
| Journal Entries | Deliberately no approval field — the posting right is the control. Organizations restrict who holds the Controller/Admin permission sets; those who can post are, by definition, those trusted to post. |
| Bank Reconciliation | A coded four-eyes rule: the person who approves a reconciliation must be different from the person who completed it. This one isn't configurable — it's enforced. |
| Payment runs | Gate the documents feeding the run: an unapproved invoice can't post, and an unposted invoice can't be paid. |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Editing Approval Status by hand to skip the queue | The field is the gate's evidence; hand-edits defeat the audit story your process exists to create | Let the approval process own the field; restrict field access if hand-edits keep happening |
| Building the process but forgetting the field updates | Approvers approve, yet the document stays unpostable — Approval Status never changed | The approve action must set Approved, the reject action Rejected; test both paths in a sandbox |
| Routing everything to one person | A vacation stalls all of AP | Use queues or delegated approvers — standard features of the platform's approval engine |
| Treating rejection as the end | Rejected documents pile up in Draft with no owner | Notify the requester with comments on rejection; fix and resubmit is the intended loop |
| Approving in email without reading the lines | The one-click convenience that approves a mis-keyed 48,000 | Open the record for documents above your comfort threshold — the email links straight to it |
Where to go next
- Automating Accounting with Flow — the other half of workflow automation.
- Segregation of Duties — the permission-set side of control.
- Posting & Voiding Purchase Invoices — what the gate is guarding.
Frequently asked questions
No. Every document except the Vendor Memo defaults to Not Required, so a small team can post everything immediately and add approvals later — the gate is there when you're ready, invisible until then.
A vendor memo reduces what you owe a supplier — which makes fabricated credits a classic fraud pattern. The cautious default means a second person always looks before a credit takes effect. You can relax it, but most controllers keep it.
Yes — entry criteria and step criteria in the approval process can read any field, including totals. A common pattern: invoices under 5,000 skip approval entirely (the process sets Approved automatically or never picks them up), 5,000–50,000 goes to the manager, above that adds the controller.
A Salesforce administrator, in Setup — it's point-and-click configuration, not code. Your accounting team's job is to specify the rules: which documents, what thresholds, who signs, in what order.
Yes — every submission, approval, rejection, and reassignment is recorded on the document with the actor and timestamp, and it can't be edited. Combined with the posting gate, you can demonstrate to an auditor that no gated document reached the ledger without its sign-off.
It stays in Draft with Approval Status Rejected — the posting gate stays closed. The usual loop: the requester reads the approver's comments, fixes the document, and resubmits. Approval Status returns to Pending while the new request is considered.
Journal entries have no Approval Status field — their control is who can post at all, managed through permission sets. If your policy demands JE review, restrict the posting permission sets to reviewers, so drafting and posting naturally separate.
Was this article helpful?