Deltek and BILL integration

What moves between them

The main flow runs from Deltek into BILL. ml-connector reads approved AP invoices from Deltek Vantagepoint and creates them in BILL as bills, mapping line amounts, GL accounts, and the project or department dimension, and it first creates or matches the BILL vendor for each Deltek Firm so every bill references a known payee. Once BILL processes a payment, the payment status, amount, method, and process date flow back so the matching Deltek AP invoice is updated and the ledger reflects what was paid. Vendor master changes are kept aligned so a bank or address change in Deltek reaches BILL before payment. BILL holds no purchase orders and is not the system of record, so projects, the general ledger, and PO data stay in Deltek and ml-connector never writes them back from BILL.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Deltek side it requests a password-grant OAuth 2.0 token against the tenant deltekfirst.com URL per customer and refreshes it before expiry, and it requires the API user role to have full field visibility so amount fields do not return as zero. On the BILL side it posts the developer key, org email, password, and organization ID to the login endpoint for a sessionId, treats any 401 as an expired session and re-logs in before retrying, and holds in-flight calls to three per org to stay under the concurrency cap. Because Deltek's webhooks are workflow-only and unsigned, ml-connector polls Vantagepoint AP invoices on a schedule rather than relying on a push. For payment status it subscribes to BILL payment and bill events and verifies each delivery by computing HMAC-SHA256 over the minified body with the subscription securityKey and comparing it to the x-bill-sha-signature header, rejecting any mismatch; because BILL disables a subscription after repeated delivery failures, it also reconciles with periodic GET calls. Neither system offers an idempotency key, so vendors are matched by name or tax ID and bills are deduplicated on the Deltek invoice number and a BullMQ jobId before posting, which prevents paying the same invoice twice. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized architecture and engineering firm with about two hundred staff runs Deltek Vantagepoint for project accounting and uses BILL to pay its subconsultants and suppliers. Before the integration, an AP clerk approved invoices in Deltek and then re-entered each one into BILL by hand to schedule payment, which meant duplicate keying, occasional mismatched vendor records, and a ledger that lagged behind actual payments until someone reconciled the two systems. With Deltek and BILL connected, each approved AP invoice and its vendor flow into BILL automatically, coded to the right GL account and project, and the payment status comes back the moment BILL processes it. The clerk schedules payments in one place, the vendor records match, and the Deltek ledger stays current without a manual reconciliation step.

What you can do

• •Create BILL vendors and bills from approved Deltek Vantagepoint AP invoices, coded to the right GL account and project.
• •Read payment status, amount, method, and process date from BILL and record it on the matching Deltek AP invoice.
• •Map Deltek GL accounts and organizations to BILL chart-of-accounts and department classifications so bills post to valid dimensions.
• •Bridge Deltek password-grant OAuth to BILL's devKey session login, re-authenticating on session expiry and staying under the three-call concurrency cap.
• •Verify BILL's HMAC-SHA256 webhook signature, deduplicate on the Deltek invoice number and jobId, and keep a full audit trail on every record.

Questions

Which direction does data move between Deltek and BILL?

The main flow is Deltek into BILL. Approved AP invoices and the vendors they reference move from Deltek to BILL as bills and vendors for payment, and the payment status, amount, and process date move back onto the matching Deltek AP invoice. BILL is used for payment execution rather than as the system of record, so projects, the general ledger, and purchase orders stay in Deltek and are never written back from BILL.

How does the integration handle BILL's session login and concurrency limit?

BILL does not use OAuth; ml-connector posts the developer key, org email, password, and organization ID to the login endpoint to get a sessionId scoped to that org. Because the session expires silently after inactivity, any 401 is treated as expired and ml-connector re-logs in and retries automatically. It also holds in-flight calls to three per org to stay under BILL's concurrency cap.

How does the integration know when a Deltek bill has been paid?

ml-connector subscribes to BILL payment and bill webhook events and verifies each delivery by computing HMAC-SHA256 over the minified body with the subscription securityKey and comparing it to the x-bill-sha-signature header. Because BILL disables a subscription after repeated delivery failures, it also reconciles with periodic GET calls on payments so a missed event does not leave the Deltek ledger stale.