BILL Security: Roles, Approvals and Payment Controls

BILL is where invoices become payments, so whoever can add a vendor bank account, approve a bill and release the money controls cash leaving the business. BILL runs the service and its payment rails, while the customer decides who holds which role, how bills route for approval, who may change vendor payment details and which integrations can act on the account. This guide covers those customer-side controls for BILL accounts payable: the built-in and custom roles, approval policies and the settings around them, vendor bank detail changes, API developer keys and sessions, accounting sync, and the reports that show whether the process was followed. It is written for finance systems owners, BILL administrators, and the security and audit teams who review them, and it goes deeper on the product than our Invoice Redirection and Supplier Bank Detail Fraud Guide, which covers the fraud pattern itself.

This is an independent guide from NHI Mgmt Group, based on BILL's public documentation as of November 2026. It is not sponsored or reviewed by BILL. Product features change, so confirm settings against BILL's current documentation.

Key takeaways

Roles are your first fraud control. BILL's built-in roles already split entering, approving and paying bills; keep Administrator to a small group and give everyone else the narrowest role.
Approval policies only help if payment waits for them. Every listed approver must approve in order, but users with "Pay unapproved bills via Bill.com" or "Pay unassigned bills via Bill.com" can pay regardless, so treat those permissions as privileged.
Lock bills once approved. The Bill Approvals setting decides whether a bill can change after approval; choose the option that blocks edits so an approved amount cannot be altered before payment.
Vendor bank details are replaced, not edited. A wrong account is deactivated and a new one added under ePayment Info, a clear event to verify by phone through a known contact before paying.
API access is a payment-capable identity. A developer key plus a signed-in session can act on the organisation, and BILL requires an MFA-trusted session for payments, bank accounts and autopay; give each integration its own BILL user with a custom role.

How identity and access work in BILL

Every person in a BILL organisation signs in with their own BILL user, and each user holds one role in that organisation. The role decides what the user can see and do across payables, receivables, banking and settings. Accountants and firms that serve several clients can hold users in more than one organisation, so a single person may have different roles in different client organisations; review access per organisation, not per person.

Built-in roles

BILL documents six built-in roles plus custom roles. The table summarises what BILL's help article says each role can do, and how we suggest using it.

Role	What BILL documents	How we suggest using it
Administrator	Full access: approve bills, authorise and schedule payments, manage user access, set up and run the accounting sync. At least one active Administrator must always exist.	Two or three named people, usually the bank signatories. Not for day-to-day bill entry.
Accountant	Enter and approve bills, record payments made outside BILL, set up and run the sync. Cannot schedule or pay bills, manage users or view banking information.	External bookkeepers and the internal accounting team who own the general ledger sync.
Clerk	Create bills and invoices, manage vendors and customers, record offline payments, view payments, bank accounts and reports.	AP processors. Because Clerks manage vendors, pair this role with a vendor change review (see Hardening baseline).
Approver	Review bills and vendor credits, then approve or deny them.	Budget holders and department heads named in approval policies.
Payer	Record and pay bills up to the approved amount; must complete identity verification to use the bank account. Cannot enter or approve bills.	Treasury staff who release payments but should not create or approve what they pay.
Auditor	Read-only view of all account and transaction information; cannot edit or approve.	Internal audit, external auditors and security reviewers during a defined engagement.
Custom roles	Created by Administrators or users with the Manage Roles permission, from scratch or by copying an existing role.	Integrations, and job roles that need a narrower set than any built-in role.

Confirm the exact permission list for each role in your own account, because BILL updates role definitions over time.

Sign-in and verification

BILL's developer documentation describes phone-based multi-factor authentication: a phone number is registered in an MFA setup step, and later challenges send a six-digit code to that phone. For the web application, confirm the current sign-in verification options in BILL's Help Center and require every user to complete them. If your organisation uses a workforce identity provider, check BILL's current documentation for the sign-in options available to your plan. See the MFA Guide for choosing factors.

BILL also runs a Know Your Customer and Know Your Business risk verification on the organisation. Its API exposes decisions such as HOLD, where money movement is disabled while BILL asks the organisation owner for more information, and REVIEW, where a manual review happens when a payment is made. Keep the organisation owner's contact details current so these requests reach the right person quickly.

Admin roles and privileged access

In a payments system, "privileged" means any permission that moves money or changes where money goes, not only user management. We treat the following as privileged in BILL and review them on a fixed schedule:

Administrator role: full control, including user management and payment scheduling. Keep the count small and named, and remove it from anyone who no longer signs on the bank account.
Manage Roles: lets a user create or change custom roles, which is a route to granting any permission. Hold it with Administrators only.
Pay unapproved bills via Bill.com and Pay unassigned bills via Bill.com: BILL's help article notes that users with these permissions, Administrators and some custom roles, can pay any bill regardless of approval status. Grant them to no one outside the Administrator group, and record why if you must.
Vendor management: adding vendors and their ePayment details. Clerks and Administrators hold it by default. It is the permission most often abused in supplier bank detail fraud.
Bank account access: Payers must pass identity verification before they can use the bank account in BILL. Keep the Payer population to the people your bank mandate already authorises.

Segregation of duties in practice

The built-in roles map neatly onto a three-way split: Clerks enter bills and vendors, Approvers approve, Payers pay. The split narrows when one person holds a role that combines steps (Administrator, or a custom role with vendor management plus payment). For a small business with two people in finance, a workable pattern is one Administrator who pays and one Accountant who enters and approves, with the owner as an Approver on bills over a threshold. Larger organisations should keep vendor maintenance, approval and payment in three different people. See the Segregation of Duties Guide and the Segregation of Duties Matrix Template to document it.

Organisation size	Suggested split (ours)	Compensating control
Two or three finance users	Owner as Administrator and Payer; bookkeeper as Accountant	Owner reviews the Bill Approval Audit report monthly; every vendor bank change verified by phone
Mid-sized AP team	Clerks enter; department heads as Approvers; treasury as Payers; two Administrators	Approval policies by amount; edits blocked after approval
Multi-entity or firm-managed	Custom roles per job; firm staff as Accountant per client organisation	Quarterly access review per organisation; Auditor role for internal audit

Approval workflows and vendor payment controls

Approval policies route bills to the right people before payment. BILL's help article states that approval policies can make sure bills over a certain amount are approved by specific people, that every approver listed on a bill must approve it, and that approvals happen in the order listed. When routing is on, Payers are not reminded to pay a bill until it is fully approved, and the Pay Bills page filters to Approved by default.

The Bill Approvals setting

Under Settings, then Payables, the Bill Approvals setting controls what happens if someone edits a bill after approval. BILL documents three options:

Option	Effect	When to choose it
Changes not allowed once approved	An approved bill cannot be edited; to change it, approvers are removed and the bill is rerouted	Our default recommendation: the amount and vendor approved are the amount and vendor paid
Changes allowed until the final approver approves	Edits are possible during routing; the final approver sees the final version	Teams that routinely correct coding during approval, with a final approver who checks totals
Changes allowed anytime until the bill is paid	Edits are possible after full approval	Only with a strong reason and a monthly review of bills changed after approval

Vendor bank detail changes

Changing where a vendor is paid is the single highest-risk action in accounts payable. In BILL, previously entered vendor bank account information is not edited in place. BILL's help article describes deactivating the incorrect account under Payables, Vendors, the vendor's Vendor Details, ePayment Info, and adding the new one through Set up ePayments with "You already have their bank information". Vendors connected through the BILL payment network (linked by Payment Network ID) update their own bank information, which takes your staff out of the change.

We suggest this procedure for every manual change:

Treat any request to change bank details, by email, phone or portal, as unverified until confirmed.
Call the vendor on a number already held on file or from a signed contract, never one in the request.
Have a second person, not the one who received the request, add the new account in BILL.
Hold the first payment to the new account for review and confirm receipt with the vendor afterwards.
Where the vendor already uses the BILL network, ask it to link by Payment Network ID so it maintains its own details.

The same pattern protects payroll; see the Payroll Diversion Fraud Guide and the Business Email Compromise Awareness for Finance Teams Guide.

Integrations, API tokens and service accounts

BILL's API acts as a signed-in BILL user. Sign-in takes four values: the username (an email address), the password, the organisation ID (an alphanumeric value beginning 008) and a developer key, which identifies the developer account. Sign-in returns a session ID that works only with the developer key that created it. BILL's documentation states that an API session expires after 35 minutes of inactivity. It also describes a user-generated token sign-in whose session ID does not expire and provides limited access to the API; treat that token as a long-lived secret.

MFA-trusted API sessions

In production, BILL requires an MFA-trusted session for the most sensitive operations:

Operation needing an MFA-trusted session	Why it matters
Enable vendor autoPay	Future bills from that vendor pay without a person releasing them
Enable recurring bill autoPayment	Recurring amounts leave the account on a schedule
Create a payment or bulk payment	Direct money movement
Create a bank account in a BILL organisation	Changes where money comes from or goes
Reset MFA	Changes the second factor protecting the identity

MFA setup registers a phone number; each MFA sign-in issues a challenge with a six-digit code to that phone, and the session becomes MFA trusted once validated. The trusted state expires, after which the process repeats.

Running integrations safely

One BILL user per integration: create a dedicated user for each connected system, with a custom role holding only the permissions it needs. A sync that reads bills has no reason to create payments. See the Least Privilege Techniques Guide.
Own the MFA phone: the phone that receives an integration's MFA codes is part of its credential. Register a phone controlled by the finance systems team, never a leaver's personal number.
Store keys and passwords in a vault: the developer key, the integration user's password and any user-generated token belong in a secrets manager, not in scripts or spreadsheets. See the API Key Management Guide.
Separate sandbox and production: BILL's sandbox uses its own gateway (gateway.stage.bill.com). Keep sandbox credentials out of production code paths.
Accounting sync: Administrators and Accountants can set up and run the sync. Assign it to a named owner, and treat the accounting system connection as a non-human identity with its own review.

Every integration user is a non-human identity that can touch payments. Inventory them alongside other machine identities; see NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.

Logging and detection

BILL's Bill Approval Audit report (Reports, then Bill Approval Audit) shows bills created or paid in a period with their approval information, so you can confirm the designated approval process was followed. It filters by Transaction Date or Created Date and downloads as CSV. Its columns include Bill ID, Vendor Name, Amount, Bill Status, Last Approved By, Next Approver, Approvals Requested, Approvals Completed, Last Payment Date and Last Payer.

Download it on a schedule and load it into your SIEM or a finance analytics workbook. Useful checks (ours):

Paid without full approval: rows where Approvals Completed is lower than Approvals Requested but Last Payment Date is set.
Self-approval and self-payment: the same person as Last Approved By and Last Payer on one bill.
Threshold avoidance: several bills from one vendor just under an approval policy amount in a short window.
New-account payments: first payments after a vendor bank account change, matched against your phone verification record.
Integration activity: payments recorded by an integration user that is meant to be read-only.

Pair the report with your identity provider's sign-in logs and a monthly export of users and roles, and diff each export against the last. See the SIEM Log Source Onboarding Checklist.

Metric (ours)	Target
Users holding Administrator	Two or three, all named bank signatories
Users with Pay unapproved or Pay unassigned bills outside Administrators	Zero
Bills paid with incomplete approvals per month	Zero, each exception explained
Vendor bank changes with a recorded call-back	100 percent
Integration users with a named owner and reviewed role	100 percent
Leavers removed from BILL within one working day	100 percent

Hardening baseline

The steps below are NHI Mgmt Group recommendations, built on the vendor settings described above.

Inventory users and roles: export every user and role in every organisation, mark Administrators, custom roles and integration users, and remove anyone without a current need.
Require verification at sign-in: make every user complete BILL's sign-in verification and register a phone they control; for integration users, use a team-controlled phone.
Turn on approval routing: build approval policies by amount, and add a second approver above a threshold your finance leadership sets.
Set Bill Approvals to block edits after approval: pilot with one team for a month, then apply to all.
Remove pay-anything permissions: strip Pay unapproved bills via Bill.com and Pay unassigned bills via Bill.com from custom roles that do not need them.
Write the vendor change procedure down: call-back verification, second-person entry and first-payment review, and encourage vendors to link through the BILL payment network.
Move integration credentials into a vault: developer keys, passwords and user-generated tokens, each with an owner and a rotation date (ours: rotate passwords annually and on staff change).
Schedule the Bill Approval Audit report: monthly review, signed off by someone outside AP.
Keep the organisation owner reachable: so risk verification requests are answered and payments are not held unexpectedly.

Roll back any step by restoring the previous role or setting from your exported baseline; keep that export for each change.

Common misconfigurations

Everyone is an Administrator: move people to Accountant, Clerk, Approver or Payer and keep Administrators to signatories.
Approval policies exist but payment bypasses them: custom roles copied from Administrator keep the pay-anything permissions. Review copied roles line by line.
Edits allowed after approval: an approved bill can then change amount before payment. Use the option that blocks changes once approved.
Bank details changed on an email request: verify by phone on a known number and use a second person to enter the change.
Integration on a person's account: the sync runs as an employee and stops or lingers when they leave. Use a dedicated integration user.
Firm access never reviewed: accountants keep access to client organisations after an engagement ends. Review per organisation every quarter.

Framework mapping

BILL control	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Built-in and custom roles, user reviews	AC-2, AC-6	PR.AA-01, PR.AA-05	5.15, 5.18
Enter, approve, pay split	AC-5	PR.AA-05	5.3
Sign-in verification and MFA-trusted API sessions	IA-2, IA-2(1), IA-5	PR.AA-01	8.5
Bill Approval Audit review	AU-2, AU-6	DE.CM-03, PR.PS-04	8.15
Shared responsibility with BILL	SA-9	GV.SC-07	5.23

Practitioner checklist

Administrator role held by two or three named bank signatories only.
No custom role outside Administrators holds Pay unapproved bills via Bill.com or Pay unassigned bills via Bill.com.
Approval policies route bills by amount, with a second approver above your threshold.
Bill Approvals set so approved bills cannot be changed.
Every vendor bank change verified by call-back on a known number and entered by a second person.
Each integration runs as its own BILL user with a narrow custom role and a team-owned MFA phone.
Developer keys, integration passwords and user-generated tokens stored in a secrets manager with owners.
Bill Approval Audit report reviewed monthly by someone outside accounts payable.
Access reviewed per organisation every quarter, including accounting firm users.

BILL Security: Set up roles, approvals and payment fraud controls