Why This Integration Matters
Bill.com handles payment execution. Salesforce handles relationship data — vendors, contracts, approval hierarchies, and workflow logic. When these systems are not connected, the gap between them is filled by human labor: someone reads the approval from Salesforce and manually creates or approves the bill in Bill.com. That manual step is the error injection point and the bottleneck.
A connected integration eliminates that step: a Salesforce approval triggers a Bill.com action directly. A Bill.com payment completion updates the Salesforce record automatically. The two systems become a single workflow rather than two separate tools with a human running between them.
Architecture Options
There are three common architectures for connecting Bill.com and Salesforce. The right choice depends on your complexity and existing infrastructure:
Option A: Native Connector (No-Code)
Bill.com offers a native Salesforce package available on AppExchange. This handles basic vendor sync and bill record sync without custom code. It is the fastest to implement but has limited customization for approval routing and custom field mapping.
Best for: Low-complexity requirements: standard AP workflow, no custom approval logic, under 200 bills/month.
Trade-off: Limited control over sync logic and no support for custom workflow triggers.
Option B: Middleware Platform (Low-Code)
Platforms like MuleSoft, Workato, or Make (Integromat) can bridge Bill.com and Salesforce using pre-built connectors. These support conditional logic and event-driven triggers without full custom code.
Best for: Medium complexity: custom field mapping, conditional routing, multi-step workflows that do not require Apex.
Trade-off: Ongoing platform cost ($150–$500/month), limited debugging capability compared to custom code, vendor lock-in on integration logic.
Option C: Custom API Integration (Code)
Build a middleware layer — a serverless function (AWS Lambda, GCP Cloud Functions) or a lightweight Node/Python service — that listens for Salesforce Platform Events or webhooks and calls the Bill.com API. Full control over logic, error handling, retry behavior, and data transformation.
Best for: High complexity: custom approval routing, high volume, complex field mapping, or requirements that middleware cannot handle.
Trade-off: Requires development resources and ongoing maintenance ownership.
Bill.com API Key Concepts
The Bill.com API (v2 REST) authenticates with a session token obtained via a login endpoint using your API key and Organization ID. Sessions expire, so production code should handle re-authentication automatically. Key objects to understand:
VendorThe payee entity. Maps to Salesforce Account (or custom Vendor object). Sync direction: Salesforce → Bill.com on create/update.
BillThe payable invoice. Contains vendor reference, line items with GL coding, due date, and approval status. The core transactional object.
BillLineItemIndividual line items within a Bill. Each has its own amount, GL account code, and optional class/location/job coding for multi-dimensional accounting.
BillApprovalPolicyDefines who must approve bills meeting specific criteria (amount, vendor, class). If your approval logic lives in Salesforce, you typically bypass Bill.com approval policies and approve programmatically via API.
PaymentRepresents an executed payment. Contains payment date, method (ACH, check, virtual card), and links back to the originating Bill. Sync back to Salesforce triggers the final status update.
WebhookBill.com supports webhook notifications for object state changes. Essential for event-driven architecture — your middleware receives a push notification when a Bill is paid rather than polling the API.
Salesforce Side: Triggering Events
The most common integration trigger is a Salesforce Approval Process completion. When a bill approval record reaches “Approved” status, you want to call the Bill.com API to either create or approve the corresponding Bill object.
In Salesforce, this is typically implemented via:
- An Apex trigger or Flow on the Approval record that fires on status change to Approved
- A Platform Event published from that trigger/flow — decouples the Salesforce action from the HTTP callout
- A Platform Event subscriber (Apex trigger or external listener) that makes the Bill.com API call asynchronously
- Asynchronous callouts are critical — synchronous HTTP calls inside Salesforce triggers cause governor limit issues at volume
Common Pitfalls and How to Avoid Them
Duplicate record creation
If your trigger fires more than once (due to Salesforce flow/trigger overlap, or retry logic after a timeout), you can create duplicate Vendor or Bill records in Bill.com. Always implement idempotency: store the Bill.com ID on the Salesforce record on first creation and check for its presence before calling create again.
Session token expiration under load
Bill.com session tokens expire after inactivity. Under low-volume conditions this is not obvious, but under burst load your middleware can encounter expired token errors. Implement token refresh logic with automatic retry on 401 responses.
GL code mapping gaps
Bill.com uses its own Chart of Accounts object. When creating Bills via API, you must reference Bill.com ChartOfAccount IDs — not your Salesforce GL codes or QuickBooks account names. Build a mapping table and sync it regularly as new GL accounts are added.
Webhook delivery failures
Webhooks can fail if your endpoint is temporarily unavailable. Bill.com retries failed webhooks, but implement a proper queue on your side and design for idempotent processing — receiving the same webhook twice should not create double-updates in Salesforce.
Test environment parity
Bill.com has a sandbox environment, but it is a separate account with no connection to production data. Your Salesforce sandbox-to-Bill.com-sandbox integration test setup requires explicit configuration and maintenance separate from production credentials.
Production Considerations
Before going live with any financial integration, verify:
- End-to-end testing with real dollar amounts in sandbox environments before production cutover
- Clear rollback plan if the integration produces unexpected behavior post-launch
- Monitoring and alerting on integration failures — a stuck AP workflow has real cash flow consequences
- Audit log of every API call and response, stored outside of both systems for compliance documentation
- Error notification routing to a shared inbox or PagerDuty integration, not just a developer email
Related Reading
Service
Salesforce Automation & Optimization
Advanced Salesforce automation including API integrations and custom Apex development.
Technical How-To
Building Approval Workflows in Salesforce with Slack
How to add Slack approve/reject buttons to your Salesforce approval process.
Case Study
Salesforce + Bill.com in Production
How a nonprofit automated expense approvals with Salesforce, Bill.com, and Slack integration.