What are RBAC and ABAC in finance? These two decentralized models determine the level of security of corporate financial data.

In finance, RBAC (Role-Based Access Control) grants permissions based on job titles (employees, managers), which is simple and common. Meanwhile, ABAC (Attribute-Based Access Control) is more flexible, controlling access by combining multiple factors such as role, geographic location, time, and transaction type, enabling more detailed and dynamic risk management, suitable for complex systems. 

This article will delve into the role of RBAC and ABAC in finance.

Why are RBAC and ABAC departments particularly important in finance?

The finance department is where the most sensitive data in an organization is concentrated, and also where the potential for internal fraud is highest if access control is not tightly managed. Common problems include:

• Financial data that is too sensitive to be shared widely includes:
• Salary and benefits vary by employee.
• Departmental expenses
• Cost of goods sold, supplier discount
• Cash flow, payment approval flow

Just one wrong authorization error can lead to data leakage or internal conflicts.

• Financial business flows require the segregation of duties according to internal control standards. In P2P (Procure-to-Pay), O2C (Order-to-Cash), and R2R (Record-to-Report), each role must be separated:
  • The PO creator cannot be the payment approver.
  • The controller cannot be the person who records the transaction.
  • Vendor creators cannot self-approve vendors.

Without RBAC/ABAC, the risk of fraud increases exponentially. Internal audit & audit requires a clear trace of authority. When errors or suspicions occur:

• Auditors need to know who has access to the data.
• Who edited the document?
• Who approves the expenditure?

This cannot be done manually or by email. RBAC/ABAC creates an accurate and consistent audit trail.

What is RBAC? – Role-Based Access Control

Advantage RBAC is easy to deploy and manage in a clearly structured environment. 

Concept

RBAC (Role-Based Access Control) is an authorization model in which users are assigned roles, and each role determines what that person can do in the system.

• User → Role
• Role → Permission
• Permission → Actions on data

That means you don't grant permissions to individuals, you only grant permissions to roles, and assign roles to individuals.

How does RBAC operate within the finance department?

The standard model of RBAC in finance is represented as a chain: Role → Permission → Action → Object. In the context of financial operations, this can be understood as follows:

Role	Permission	Action	Object
AP Maker	Create a document	Create	Payment Request
AP Checker	Check the invoice	Review/Verify	Invoice
Approval	Approve expenses	Approve	Expense/Invoice
CFO	Full access	View/Approve/Report	Budget, Cost, GL

Real financial institution simulation example:

• AP Maker: Create payment vouchers, enter invoices, attach documents.
• AP Checker: Check invoice validity, 3-way match (PO – GR – Invoice).
• Approver (Line Manager/Director):  Expenditures are approved by department or according to assigned budgets.
• CFO: View the complete budget, expenses, cash flow report, and closing report.

RBAC helps each person know exactly their scope – no confusion.

Advantages of RBAC

RBAC is suitable for most businesses that are new to implementing financial controls for the following reasons:

•  Easy to audit: “who is authorized to do what, on what data?”, Clear audit trail, easy to prove compliance.
•  Easy onboarding/offboarding of personnel, no need to manually set permissions.
  • New employee → assign role → use immediately
  • Employee leaves → remove role → remove all privileges

•  Enhanced Separation of Duties (SoD): RBAC helps enforce SoD in financial processes and reduce the risk of internal fraud.
  • The person creating the document cannot approve it themselves.
  • The reviewer cannot pay himself.
  • The vendor creator cannot approve the vendor themselves.

Limitations of RBAC

Although simple and effective, RBAC still has many limitations when businesses expand – especially in multi-company, multi-branch, multi-cost center.

• Role Explosion – The number of roles is increasing rapidly.

For example, if a business has 5 departments and 4 levels of approval limits, RBAC must create more than 5 departments. 20 different rolesThe larger the RBAC, the harder it is to maintain.

• Complex logic is not supported.

RBAC is insufficient for dynamic rules such as:

• Approval by limit (eg: <30M at Department Head level, <100M at Director level)
• Browse by department/budget
• Browse by document type (Capex vs Opex, PO vs Non-PO)
• Browse by location/branch
• Browse by brand or project

Because RBAC only manages by “role”, it does not consider the actual data of the document.

• Not optimal for multi-entity businesses

A business with multiple subsidiaries will need permissions to:

• AP Maker of company A cannot view company B's invoices
• Brand manager X is not allowed to review brand budget Y.

Pure RBAC is context-insensitive, leading to data exposure.

What is the difference between RBAC and ABAC in finance?

The table below summarizes the core differences between RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control), based on the actual needs of the finance and accounting department.

Criteria	RBAC	ABAC
How to grant permissions	Based on a fixed role.	Based on dynamic attributes (user – document – context)
Level of flexibility	Average – suitable for processes with few variations	Very high – meets complex approval logic and multiple conditions
Suitable for this type of business	Small and medium-sized enterprises, simple processes, not too many approval levels.	Large enterprise, multiple branches, multiple legal entities, multiple cost centers & brands
Risk control	Good for Separation of Duties (SoD)	Excellent for multi-level control, limits, budgets, vendor risk…
System Administration	Easy – role-based management	Complex – need governance, policy engine
Scalability as the business grows	Limitations (Role Explosion)	Very good – only expands by attribute
Popular applications	ERP traditional, HRM, small systems	Modern ERP, AP Automation, Treasury, EPM, Workflow engine

Applications of RBAC and ABAC in finance and accounting. 

In finance and accounting, every transaction involves money, compliance, risk, and sensitive data. Therefore, applying RBAC/ABAC is not only a “best practice”, but also a mandatory requirement for safe and efficient operations as the business grows.

Accounts Payable (AP) – P2P

RBAC in AP is used to separate tasks and ensure SoD:

• AP Maker → Create PR/PO, enter invoice.
• AP Checker → Verify validity, compare PO–GR–Invoice.
• Approval → Approve payment.
• Treasury → Make the payment.

RBAC guarantees Creators cannot self-approve; approvers cannot self-pay..

ABAC in AP is used to handle complex rules based on budget – cost center – limits:

• Only Marketing Managers are approved. < 50 million for marketing costs.
• Controller approves if vendor risk = high.
• CFO approves if Invoice > 200 million or exceeding the departmental budget.
• AP staff only saw invoices belonging to Company A (attribute = company).

ABAC helps P2P systems automatically select the right reviewer → reduce errors, increase compliance.

Accounts Receivable (AR) – O2C

RBAC in AR is clearly separated to prevent fraudulent write-offs/reductions of liabilities.

• Sales Admin create invoice
• AR Officer Record cash receipts – reconcile.
• AR Manager approve debt adjustment

ABAC in AR operates more transparently – reducing the risk of data manipulation.

• Only AR is responsible Southern region View accounts receivable in Southern Vietnam.
• Only allow debt adjustments if Invoice not yet confirmed..
• Automatically escalate to Finance Manager when DSO exceeds 45 days..
• Only CEOs can view aggregated AR reports by brand/company.

Treasury

RBAC in the Treasury:

• Separate: cash forecaster – payment maker – payment approver – reconciler.
• Minimize the risk of transferring money incorrectly or fraudulently.

ABAC in Treasury protects a company's cash reserves with dynamic risk-based policies.

• Payment limits are based on type of cost, currency, account level.
• Payment exceeding 500 million VND is mandatory. 2 approvers and must be from Company IP/VPN.
• Only the Treasury department views the cash flow details for each account; the CFO views the consolidated results.
• Control international transactions based on risk criteria (country risk score).

General Accounting – R2R – Closing

RBAC in R2R

• Company A's accountant only records company A's journal.
• General accountants review and consolidate data.
• Controller/Chief Accountant approves adjusting entries.

ABAC in R2R

• Only allow journal posts if sub-ledger reconciled.
• Do not allow editing of data after locked period.
• Separate the right to view salary by department and Sensitivity attribute.
• Policy: Journal > 200 million → require CFO approval.

Ensure transparent closing process, reduce end-of-period discrepancies.

FP&A – Reporting & Budgeting

RBAC in FP&A

• FP&A Analyst views data by assigned legal entity.
• The FP&A Manager reviews the entire budget and forecast.
• The CFO views the consolidated view across the entire corporation.

ABAC in FP&A helps companies secure sensitive data & control budgets accurately.

• Data viewing permissions cost center, project, brand, region.
• Only departments can view their own budget.
• Conditional budget overstay alert: “If spend > 110% budget → send notification to Controller”.
• Only allow budget file download when user access from internal VPN.
• Filter payroll data by sensitivity → only HR and CFO can view full details.

What is the technology that supports RBAC and ABAC in finance?

RBAC and ABAC are not just "decentralization models," but the backbone of financial control. However, businesses cannot implement them effectively without technological support. Below are some technology solutions to support RBAC & ABAC.

ERP system

SAP / Oracle / Dynamics 365

• It provides a very powerful RBAC, allowing for detailed role assignment by module (AP, AR, GL, Asset, etc.).
• ABAC support through Policy Engine or BRF+ (Business Rule Framework) → can create rules by limit, cost center, project, and document type.

Odoo / MISA / BRAVO / FAST

• Mainly based on traditional RBAC.
• Not flexible enough for businesses with multi-tiered, multi-company, or complex budget approval processes.

IAM – Identity & Access Management

Platforms like Azure AD, Okta, Auth0 provide:

• SSO: 1 account with full access to ERP, AP Automation, Treasury, and EPM.
• MFA: Increase security for sensitive tasks like payment approvals.
• Conditional Access (ABAC): limit access by device, IP, time, location.

IAM acts as the "foundation" for RBAC/ABAC, helping to synchronize authority across multiple financial systems.

AP/AR Automation

Modern AP/AR Automation solutions (e.g. Bizzi IPA, Tipalti, Coupa, Airbase) should have:

RBAC

• Mapping available roles AP Maker, Checker, Approver, Treasurer, CFO.

ABAC

Policy Engine supports rules according to:

• Approval limit (approval limit).
• Departmental Budget / Cost Center.
• Type of document (invoice, PO, expense claim).
• Vendor Risk / Payment Risk.
• Project, contract, and workflow specifics..

Multi-level Approval

• Automatically identify reviewers by rule → avoid having to create 20–30 roles like traditional RBAC.

Cost Center-Based Access

• Employees only see data within their department.
• CFO/FP&A can view cross-company or consolidated view.

Audit Logging – Mandatory for Finance

To support internal and independent audits, the system needs detailed logs:

• Who sees what data? (Data Access Log)
• Who edited the documents? (Change Log)
• Who approves over-limit spending? (Approval Exception Log)
• Who creates, deletes, and updates vendors? (Vendor Master Log)
• Suspicious login session (Abnormal Access)

Audit logs are a mandatory component in both RBAC and ABAC for risk control.

Compliance – Risk – Audit: Why do RBAC and ABAC play a core role in finance?

RBAC/ABAC is not just a decentralization technique, but a foundation for risk control, compliance, and transparency throughout the entire corporate financial system. This is due to the following four pillars:

1. Segregation of Duties (SoD): A mandatory requirement in finance

SoD guarantees no single individual owns the entire processRBAC/ABAC helps automate SoD by:

• People create Invoice cannot be self-censorship.
• People browse cannot self-checkout.
• People vendor update It is not possible to create a payment voucher for that vendor.

SoD = the foundation for reducing the risk of fraud and errors in AP, AR, Treasury, and GL.

2. Prevent Internal Fraud

RBAC/ABAC dramatically reduces the risk of fraud by limiting permissions based on roles + conditions.

Common types of fraud in finance:

• Fake invoice.
• Self-approval: self-create – self-approve – self-pay.
• Bypass limit: approve large expenses using an unauthorized account.
• Manipulate vendor: add virtual vendor yourself and pay.

How RBAC + ABAC prevents:

• Only AP Maker role can create invoices, but approval must be Checker or Approver.
• ABAC blocks approval if the amount > limit or is not in the approver's cost center.
• The Treasury only pays amounts that have passed the proper approval process.

Reduce fraud risk upfront, without post-processing.

3. Meet compliance & audit standards

International standards require clear, transparent and auditable access controls:

ISO 27001

• Requires role-based access control + principle of least privilege.
• RBAC/ABAC meets the requirement of separation of rights and restriction of access by attributes.

SOC 2 (Security – Availability – Confidentiality)

• Request full Audit Log: who viewed what, who edited what.
• ABAC supports rule-based access, reducing the risk of incorrect data access.

SOX (Sarabines–Oxley) – for publicly listed companies

• Access control in AP/AR/GL is a mandatory feature.
• RBAC/ABAC helps establish SoD and approval control → meets Internal Control over Financial Reporting (ICFR).

Without an RBAC/ABAC model, businesses no pass Independent audit and internal audit.

4. Zero Trust Finance Model

Zero Trust applied to finance = "No one is automatically entitled to a right.".

Principle:

• No override permissions were granted.
• Don't trust someone based on their title.
• Rights are only granted when appropriate role + attributes + context.

RBAC + ABAC = Zero Trust platform in finance:

• RBAC: “who does what” framework.
• ABAC: conditional control (limits, cost centers, document types, etc.).

The two models combine to form “Least Privilege Finance”: everyone only sees and does what they are allowed to.

What is Bizzi's role in implementing RBAC & ABAC in modern finance?

Businesses increasingly require tight access control, clear separation of duties, and budget/limit approvals. Bizzi is designed to integrate both RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) across the entire finance and accounting workflow.

Bizzi not only decentralizes by role but also manages permissions by budget, cost center, limit, project, spending category, suitable for the control model of large enterprises.

Bizzi Expense – Budget Decentralization & Expense Approval

RBAC – Role-based hierarchy:

• Employee → Department Head → CFO.
• Each role has the right to create - view - approve according to clearly defined regulations.

ABAC – Authorization by Financial Attributes:

• According to the limit: The system automatically determines the approval level based on the value of the expense.
• According to the budget departmentOnly the management level of that department is authorized to approve.
• By type of spending (OPEX/CAPEX/Marketing/Travel…).
• Automatically block over budget in real time.

Bizzi Expense ensures that all expenses are approved correctly – within the allocated limit and budget, minimizing the risk of fraud and overspending.

Bizzi AP Automation – Invoice Control with RBAC + ABAC

RBAC – Separation of Duties in AP:

• Maker → Checker → Approver.
• Ensure SoD (Segregation of Duties) meets audit standards.

ABAC – Attribute-Based Access Management:

• Departmental accountants can only view invoices belonging to their own department (cost center-based access).
• Block users who are not "cost owners".
• Block over-budget invoices, do not allow creation or approval.
• View/browse depending on vendor risk, document type or invoice value.

Bizzi helps businesses maintain AP control according to Internal Control – ISO – SOX standards, significantly reducing the risk of fake invoices, incorrect accounts, or unauthorized self-approval.

Bizzi ARM – Decentralize debt according to responsibility and customer

Bizzi ARM (Accounts Receivable Management) feature – Accounts Receivable Authorization by Responsibility and Customer provides a more organized and secure way to manage receivables by limiting access and manipulation of receivables data based on the specific roles and responsibilities of each employee.

RBAC:

• Sales/Customer Service Staff → Confirm outstanding debt.
• AR Accounting → Management – reconciliation.
• CFO → Track the entire business.

ABAC – Delegation of authority based on “customer ownership”:

• Employees are only allowed to view accounts receivable from customers under their responsibility.
• Departments only view debts within their own region/segment.
• The CFO and controller see all accounts payable to assess cash flow risk.

Bizzi ARM helps businesses avoid situations where employees accidentally access sensitive data, while also increasing transparency in accounts receivable management.

Sactona EPM – Control rights in planning & forecasting

Sactona is a business management software/system solution (EPM/FP&A – planning, budgeting, forecasting, analysis) developed by Outlook Consulting. In Vietnam, Bizzi is the exclusive distribution partner and official implementation support for Vietnamese businesses. In supporting RBAC & ABAC, Sactona solves the following problems:

RBAC:

• FP&A: Data Entry – Analysis.
• CFO: approval – see summary.
• Manager: enter department plan.
• Viewer: only allows viewing the dashboard.

ABAC – Managing Rights Based on Financial Structure:

• Restrict viewing or input rights as follows:
  
  • Subsidiary
  • Cost center
  • Project
  • Region/Cluster
• Limit according to fiscal period (monthly/quarterly/yearly) to avoid making edits outside of the scheduled period.
• Input conditions are based on quota, target, or key driver.

Sactona helps ensure that planning data – forecasts – are always accurate, transparent, and controlled according to modern EPM standards.

Conclude

Above is all the information related to RBAC and ABAC analysis in finance. For small businesses, the RBAC model is enough to control the financial and accounting process because of the simple structure, few departments and few approval layers. However, when the business grows to medium size or larger, the need to control by budget, limit, cost center or type of cost becomes more complicated, making RBAC alone no longer sufficient. At this time, the hybrid model combining RBAC and ABAC is the optimal choice. 

For large enterprises with multiple branches, multiple departments, multiple approval processes and strict control requirements, ABAC is almost mandatory to ensure transparency and compliance. Finally, enterprises that prioritize fraud prevention, cash flow transparency and move towards the Zero Trust Finance model should choose financial platforms that integrate both RBAC and ABAC with audit trail – typically Bizzi – to operate a more efficient, secure and automated control system.

Register here to receive a customized solution tailored specifically for your business: https://bizzi.vn/dang-ky-dung-thu/