ALLMSP Blog

BILL Access and Payment Security: Roles, 2FA, Approval Limits, and Offboarding

A control-focused guide to BILL identity, predefined and custom roles, separation of duties, 2FA or MFA, approval thresholds, bank and payment authority, evidence review, incident containment, and complete offboarding.

Bill Com access-payment-security-roles-2fa-offboarding support for a Georgia business

BILL access is unusually consequential because the same platform can hold invoices, vendor and customer records, approvals, bank or card funding choices, payments, receivables, accounting sync, and audit history. Security must therefore answer two questions for every identity: what information can the person reach, and what movement of money can the person initiate or authorize? A login that looks harmless in a user list can still carry accumulated operational power through its role, client entities, approval assignments, or administrator duties.

BILL currently documents default roles that include Administrator, Accountant, Approver, Payer, Clerk, and Auditor, along with custom-role capabilities in eligible plans. BILL's security pages describe role-based access, separation of duties, 2-Factor Authentication or Multi-Factor Authentication, audit trails, and prompt access removal. Product materials also describe approval groups, amount-based policies, Single Sign-On, and Dual Control where available. Treat availability as account-specific and verify the current control in the live tenant before relying on it.

The objective is not to maximize prompts or force every payment through an identical path. It is to align BILL permissions and approvals with documented authority, make emergency action possible without permanent overprivilege, and retain evidence that an independent reviewer can follow. This guide covers software access and payment controls; it does not replace bank authorization, insurance requirements, legal advice, or a broader business-email-compromise response plan.

Key decisions at a glance

  • Use individual BILL identities and test effective permissions across Administrator, Accountant, Approver, Payer, Clerk, Auditor, and applicable custom roles.
  • Require BILL's current 2FA or MFA controls and manage recovery through verified identity procedures that never ask staff to share codes or passwords.
  • Separate vendor or bill entry, approval, payment scheduling, bank administration, sync, and reconciliation so one user cannot silently control the full transaction.
  • Apply amount and policy limits with explicit approvers, groups, escalations, and Dual Control where the account supports it; verify behavior with real test cases.
  • Offboarding is complete only after BILL access, sessions, roles, payment authority, bank responsibilities, integrations, inbox ownership, and evidence are independently checked.

Design BILL roles around duties and separation of payment power

Bill Com support workflow: Design BILL roles around duties and separation of payment power
Bill Com support workflow: Design BILL roles around duties and separation of payment power

Inventory duties before assigning roles. Bill entry may require invoice and vendor access but not payment scheduling. An approver may need documents, coding, comments, and approval status without bank administration. A payer may need approved bills and funding choices but not the ability to create or change the invoice. An accountant may need sync and reconciliation without user administration. An auditor should receive evidence-oriented access appropriate to the engagement. Define these boundaries separately for every client entity a CPA firm manages.

Map BILL's default and custom-role permissions to positive and negative test cases. The developer documentation lists Administrator, Accountant, Approver, Payer, Clerk, and Auditor roles; BILL product pages describe custom roles and granular permissions in supported plans. Do not infer a permission from the role name. Test whether a user can add or edit vendors, view bank details, export data, change approvals, schedule or cancel payments, administer other users, change sync preferences, and inspect reports.

Find toxic combinations and permanent exceptions. A person who creates a vendor, changes remittance information, enters a bill, approves it, selects a funding account, pays it, and reconciles the ledger can bypass multiple reviews. A small team may be unable to separate every action, but it can add independent review, amount limits, out-of-band verification, transaction alerts, and documented owner oversight. Temporary elevated access needs an approver, expiry, activity review, and confirmed removal rather than a calendar reminder alone.

  • Build a BILL entitlement matrix by entity, role, task, sensitive data, money action, approver, compensating review, and expiration date.
  • Test allowed and denied actions with representative users instead of relying on role names, inherited templates, or screenshots from another account.
  • Flag combinations involving vendor changes, bill entry, approval, payment, bank setup, user administration, sync preferences, exports, and reconciliation.
  • Review administrator, payer, custom-role, cross-client, and dormant access at least quarterly and after every job, entity, or service-model change.

Operate BILL 2FA or MFA, recovery, sessions, and privileged access safely

Bill Com support workflow: Operate BILL 2FA or MFA, recovery, sessions, and privileged access safely
Bill Com support workflow: Operate BILL 2FA or MFA, recovery, sessions, and privileged access safely

Require each person to use an individual BILL account and complete the multifactor control currently supported for that account. BILL documentation uses both 2-Factor Authentication and Multi-Factor Authentication terminology and states that MFA protects secure login; the developer documentation also identifies payment creation as an MFA-trusted operation. Do not weaken the control through shared phones, forwarded codes, common email accounts, or password-sharing. Enrollment and sign-in tests belong in onboarding and the production-readiness checklist.

Treat recovery as a privileged identity event. Keep the current official recovery route available, verify the person through an independent channel, and record who authorized and completed the action. Help desk staff, accountants, administrators, and executives should know that legitimate support will not need another person's one-time code. After a lost device, suspicious login, unexpected challenge, or email compromise, contain access, review recent activity, secure the email identity, and validate payment and vendor changes before normal use resumes.

Reduce standing exposure beyond login. Use SSO where it is available and appropriately governed, protect administrator email accounts, limit persistent browser sessions on shared or unmanaged devices, and prohibit public-computer access. Maintain at least two accountable administrators only when duties and review justify it, so recovery does not depend on one person. Emergency privilege should be time-bound, monitored, and removed immediately after the approved task and independent verification.

  • Enroll and test BILL's current 2FA or MFA control for every human identity before granting production access or payment responsibility.
  • Define an identity-verified recovery procedure that prohibits shared credentials, shared codes, improvised bypasses, and unrecorded administrator intervention.
  • Investigate unexpected challenges, device loss, email compromise, suspicious sessions, and unexplained vendor or payment changes as connected events.
  • Protect administrator and payer email accounts, remove unmanaged sessions, and review emergency elevation from request through expiry and removal.

Control approval limits, bank authority, vendor changes, and payment evidence

Bill Com support workflow: Control approval limits, bank authority, vendor changes, and payment evidence
Bill Com support workflow: Control approval limits, bank authority, vendor changes, and payment evidence

Translate the signed financial-authorization policy into BILL approval policies, groups, amount bands, and required sequences. Product documentation describes policy criteria, separation of duties, and Dual Control where available. Test exactly how a bill matches a policy, how groups satisfy a step, how edits affect routing, and how bills created before a policy change behave. The test set should include threshold boundaries, new vendors, credits, urgent payments, recurring items, and an unavailable approver.

Govern bank and payment authority separately from invoice approval. Identify who may add or verify a funding account, choose a bank or card, schedule a payment, request faster delivery, cancel or void, change a vendor's payment instructions, and resolve a failed funding. Require out-of-band vendor verification for remittance changes and independent review of new or changed bank relationships. A message inside a compromised mailbox is not sufficient proof of a vendor's instructions.

Preserve evidence for each high-risk event. BILL describes timestamped audit trails for original bills, notes, approvals, payments, and remittance details. Retain the source invoice, vendor validation, policy match, approval identities and times, payment status, funding choice, delivery outcome, accounting entry, clearing result, and any exception decision. Reviewers should be able to connect a bank debit and ledger posting back to an authorized business obligation without relying on one user's explanation.

  • Test approval thresholds at values below, exactly at, and above each boundary, including group, sequential, absence, denial, and edit scenarios.
  • Require independent verification and dual review for vendor remittance changes, funding-account changes, new payees, and unusual payment instructions.
  • Separate invoice approval from scheduling, funding selection, cancellation, void, and reconciliation unless a documented compensating control is active.
  • Export or retain transaction evidence according to policy so audit history remains available for internal, client, bank, insurer, and auditor inquiries.

Run access reviews, incident containment, and complete offboarding

Use a recurring access review that starts with authoritative employment, contractor, and client-service records. Compare active BILL users, roles, entities, approval assignments, payer authority, administrators, SSO status where applicable, and recent activity with current duties. Pay special attention to dormant identities, former client teams, generic mailboxes, assistants or delegates, custom roles, and people who changed departments. The reviewer must be independent of the person who last granted the access.

Trigger urgent containment for termination, suspected compromise, unauthorized vendor change, or questionable payment. Remove or suspend the person's access through the current supported workflow, protect their email account, revoke sessions where possible, preserve audit evidence, and place appropriate holds on pending payments or vendor changes. Notify the bank, BILL, insurer, counsel, or law enforcement when the incident plan requires it. Avoid deleting evidence in an effort to tidy the account.

Finish offboarding with a transaction and ownership check. Remove roles and entity access; replace approver and payer assignments; transfer inbox, reports, integrations, recurring responsibilities, and vendor communications; secure credentials or keys; review recent approvals, payments, exports, and changes; and test critical workflows. Record the request, authorization, timestamps, evidence reviewed, transfers completed, residual exceptions, and independent verification. A disabled mailbox alone does not close BILL authority.

  • Reconcile BILL access to authoritative personnel and client rosters, then have an independent owner approve every privileged or exceptional assignment.
  • For urgent cases, contain identity and payment risk first, preserve evidence, and then complete ownership transfer and permanent access removal.
  • Replace approvers, groups, payers, administrators, inbox owners, report recipients, integration owners, and vendor contacts before deleting dependencies.
  • Test that the departed person cannot sign in or act and that required bills, approvals, payments, syncs, and reconciliations still complete correctly.

Frequently Asked Questions

Which default user roles does BILL currently document?

BILL's current developer documentation lists Administrator, Accountant, Approver, Payer, Clerk, and Auditor. Exact permissions and custom-role availability can depend on the product and plan, so test effective access in the live account rather than relying only on the name.

Should a BILL administrator also approve and pay every bill?

Not by default. Administrator, approval, and payment powers should reflect the written authority model. If a small team combines duties, add independent review, amount limits, vendor-change verification, alerts, reconciliation, and periodic evidence review as documented compensating controls.

Does BILL support two-factor or multifactor authentication?

Yes. BILL's current materials describe 2-Factor Authentication and Multi-Factor Authentication as account protections, and the developer documentation identifies payment creation as an MFA-trusted operation. Follow the live supported enrollment and recovery workflow for the specific account.

Can employees share a BILL login if they perform the same role?

No. Individual identities preserve attribution, multifactor enrollment, activity evidence, recovery responsibility, and precise offboarding. Shared credentials make it difficult to determine who changed a vendor, approved a bill, scheduled a payment, or exported sensitive data.

What BILL actions need the strongest separation of duties?

Prioritize vendor and remittance changes, bill entry, approval, payment scheduling, funding-account administration, user or role administration, sync preferences, exports, cancellations or voids, and reconciliation. No one person should invisibly control the complete obligation-to-cash path.

How should a vendor bank change be verified before payment?

Contact a known vendor representative through an independently sourced channel, compare the request with trusted records, document the confirmation, and require review by someone other than the person who entered the change. Do not rely only on the email thread containing the request.

What should a BILL approval-limit test include?

Test amounts below, exactly at, and above each threshold; named and group approvers; sequential steps; denial; absence; editing; credits; new vendors; urgent payments; and bills created before and after a policy change. Capture both routing and payment eligibility results.

What evidence should be reviewed after a suspected BILL compromise?

Preserve login and user activity, role changes, vendor edits, approvals, payments, bank or card changes, exports, sync settings, inbox actions, email evidence, and accounting entries. Correlate timestamps and avoid deleting records before the incident owner approves retention and recovery steps.

What must be transferred during BILL offboarding?

Transfer approver groups, payer and administrator duties, inbox queues, report schedules, integrations, recurring tasks, vendor communications, accounting reconciliation, and open exceptions. Then remove access and independently test that critical AP and AR workflows still operate under supported ownership.

How often should BILL access be reviewed?

Review privileged and payment-related access at least quarterly and immediately after employment, contractor, client, entity, or role changes. Higher-risk firms may review administrators, payers, vendor-change rights, and cross-client access more frequently based on volume and threat exposure.

Facebook
LinkedIn
WhatsApp
X
Email
Print
Threads
Reddit

Related Articles