Review and authorize transactions

Submitting a Transaction freezes its current posting for maker-checker review. The required authorization depth is resolved from permissions and any matching conditional access policies using the complete transaction facts.

Access required

You need Read Transaction to open the record. Acting at a pending stage requires the matching Approve Transaction L3, L2, or L1 permission, applicable conditional-policy authority, and authorization scope for the transaction's booking Branch.

The maker or any user who already acted in the approval chain cannot approve, reject, or deny that same transaction.

Review the transaction

1. Open Customer Relationship → Transactions → Transactions.
2. Open the transaction reference.
3. Compare the header Branch, Posting Date, Value Date, Intent, and narrative with the source instruction.
4. Review every batch's Transaction Code, debit and credit Accounts, line currencies, amounts, and base-currency totals.
5. Review Commission Decisions and any FX source, override, deviation, and conversion evidence.
6. Confirm both the Approval status and Processing status shown beside the reference.
7. In Workflow, select Approve, Reject, or Deny when the action is available to you.

remoteEaze revalidates transaction intent before each approval. At final authorization it also verifies referenced Accounts and available Facility capacity before the posting is queued.

Approval sequence

The resolved number of levels determines the first pending status:

The action available at each stage requires that exact level's approval permission. Holding L1 permission does not authorize an L2 or L3 action.

After final approval, Approval becomes Authorized and ledger processing is dispatched. Processing remains Pending while the posting runs, becomes Processed on success, and becomes Failed with a displayed failure reason when posting cannot complete.

Booking-branch scope

Transaction authorization uses the header Branch as its data-access boundary. For a branch-scoped authorizer, that booking Branch must be in the user's accessible Branches.

Line Account Branches are still recorded and are available to conditional access policies, but they do not independently prevent authorization. This is intentional: one transaction can post across several Branches while remaining owned and authorized through one booking Branch.

Maker access is slightly broader than authorization access. A transaction can remain visible to its creator or last modifier under maker-oriented scope, but that relationship does not grant authority to approve it outside the user's booking-Branch scope.

See Data-access scope for the wider access model.

Conditional access policies

Policies can use header, line, Account, amount, currency, commission-payer, reversal, and time facts to allow or block submission and approval or to override the required approval depth. The policy amount for a Transaction is its total Debit value in the company base currency.

A normal permission does not bypass a matching policy. If the action is not available or is rejected, confirm the policy's role, entity, Branch, amount, currency, time, and required-level rules with an administrator. See Conditional access policies.

Reject or deny

Reject returns a pending Transaction to Rejected with a mandatory reason. Its approval chain is cleared. The maker can use Edit to correct the record and Save & Submit to start authorization again.

Deny moves the Transaction to Denied permanently. Use it only when the record must not be corrected and resubmitted. Both actions require the current stage's approval permission and enforce maker-checker separation.