Sage Intacct: Bill Payments, Payment Methods & Entities

A practical guide to creating AP bill-payments through the Apideck Accounting API on Sage Intacct, choosing the right payment_method, and understanding how single- vs. multi-entity setup affects what you see in responses.

This consolidates the common Sage Intacct questions integrators hit during onboarding, in the order they usually come up: get a payment to post → pick the method value → understand entities and company_id.

Sage Intacct requires a payment method on every AP payment. When it's missing, the API returns a generic error — BL34000094 — that does not name the missing field, which makes it easy to misdiagnose.

company_id is not the cause of payment-creation failures. A common false lead: a failing call also happens to be missing company_id, so it looks like the culprit. It isn't. Isolating the variables (two identical calls, one with payment_method and one without) shows the call without payment_method fails with BL34000094 and the one with it succeeds. company_id is not needed to create a bill-payment.

{
  "supplier": { "id": "20747" },
  "account": { "id": "84" },
  "currency": "USD",
  "transaction_date": "2026-06-09",
  "total_amount": 5000,
  "payment_method": "EFT",
  "allocations": [
    { "id": "4813", "type": "bill", "amount": 5000 }
  ]
}

The payment_method value must match a method configured in the Sage Intacct company (see Section 2).

Sage Intacct's payment method is a small, fixed set of system values. It is not per-vendor or per-invoice — the same set applies to every bill in the company. Hardcoding a single value in your bill-payment object is the correct approach: it's consistent across all bills, which is the "concrete and unanimous" property you want for an automated integration.

You cannot configure a custom payment method "for TM-payable invoices." Sage Intacct does not support a custom per-invoice payment-method type on the AP payment object — payment_method is just one of the system values. To mark which payments originate from TransferMate, use a free-text marker (e.g. reference, the document number, or a custom field), not the payment method.

There is no dedicated Apideck (or connector) endpoint that lists payment-method types for Sage Intacct. The unified payment_method field is a free-text string passed straight through to Sage's PAYMENTMETHOD field. You don't need the Sage UI to discover valid values — read them from existing payments:

Each record also returns a payment_method_reference (Sage's internal key):

Sage's full system set also includes Charge Card and Record Transfer, but the values above are what's actually configured on this tenant today. Pass the value exactly as shown (e.g. "payment_method": "EFT").

Recording an AP payment with payment_method: "EFT" does not require any EFT/ACH setup on the vendor or funding account. Confirmed live on the sandbox:

• POST /accounting/bill-payments with payment_method: "EFT", supplier 20016, funding account 84 (100_SVB), $1 against bill 1152 → 201 Created (payment 4910).

• Read-back confirmed payment_method: EFT, payment_method_reference: 5, status paid.

• The decisive detail: that vendor has no ACH bank details set up — every supplier on the tenant returns bank_accounts: null — and the EFT payment still recorded cleanly.

EFT setup only matters for generating a real disbursement file. You'd only need vendor/account EFT configuration if Sage has to generate an actual ACH/EFT payment file — not for recording the method. For TM's use case (recording that a payment occurred, settled via electronic bank transfer), EFT is good to go as-is.

• Via the API: GET /accounting/suppliers/{id} — if the vendor has ACH details they appear under bank_accounts[].account_number (mapped from Sage's ACHACCOUNTNUMBER). Empty/null means no ACH details. The underlying Sage VENDOR object also carries ACHENABLED, ACHBANKROUTINGNUMBER, and ACHACCOUNTTYPE.

• Via the Sage UI: Vendor → Payment information tab (ACH/bank details, "Enable for ACH"); and Cash Management → the bank account → its supported payment methods.

Sage Intacct companies come in two shapes, and which one a customer uses determines how you set up the connection and what you see in responses. If you've integrated NetSuite, this is the Sage Intacct equivalent of the OneWorld vs. basic distinction.

Locations are not entities. A single-entity company can still segment data with locations (e.g. USA1, USA2). Locations are reporting dimensions within an entity — they don't make a company multi-entity, and records under them don't carry an entity id. Only true entities (e.g. 100/200/300) populate company_id.

There's no single "edition" flag (no explicit OneWorld/basic toggle). Instead, read the entity list — the same data that powers the Default Entity dropdown when creating a connection:

GET /accounting/companies

• Returns entities → the company is multi-entity. Set a Default Entity on the connection.

• Returns nothing (only "Top level") → treat it as single-entity. Use "Top level".

Branch your onboarding logic on whether that list is empty. This is the closest thing to NetSuite's OneWorld/basic distinction.

In Sage Intacct, company_id corresponds to the multi-entity dimension. It's populated only when a company is set up with Intacct's multi-entity console and the record belongs to an entity. For single-entity (location-based) companies, company_id comes back empty on bills, suppliers, and other records — this is expected, not a gap.

Use the entity list as your multi-entity signal, not the presence of company_id on transactions. The dropdown/scoping comes from Intacct's location/entity dimension, whereas company_id is populated only by the separate multi-entity console. A client can have entities in the dropdown and still get an empty company_id on records.

If location identity is what you actually need, it's surfaced at the line-item level on a single bill: GET /accounting/bills/{id} → line_items[].location_id.

When you create a Sage Intacct connection, the Default Entity you choose scopes every read and write on that connection:

• Pick a specific entity → all calls operate within that entity.

• Pick Top level → calls operate at the top level.

Scope is applied when the connection's session is established, so in practice it's fixed per connection. To work across multiple entities, create one connection per entity.

Entities are isolated. A record created under entity USA1 belongs to USA1. A Top-level connection will not list records created under a child entity — to read USA1's bills/vendors, the connection's Default Entity must be USA1. (This is expected Sage Intacct behaviour and confirms entity scoping is working.)

The Default Entity dropdown lists only the entities the Web Services user has permission to access in Sage Intacct. If an entity is missing, grant that user access to it in Sage Intacct (User → entity permissions) and it will appear.

Yes, but it's a configuration change on the Sage Intacct side, not something toggled through Apideck. Sage supports upgrading a company from single- to multi-entity, but it's a significant and generally permanent change made within Sage Intacct. On a shared sandbox this should be coordinated with the CSM rather than flipped unilaterally.

1. Create the connection with the customer's Sage Intacct credentials.

2. Call GET /accounting/companies to determine single- vs. multi-entity.

3. Multi-entity: set the Default Entity (one connection per entity you need to operate in). Single-entity: use Top level.

4. Don't rely on company_id appearing on records as your multi-entity test — use the entity list.

5. If an expected entity is missing from the dropdown, fix the Web Services user's entity permissions in Sage Intacct.

6. For bill-payments, always include payment_method. Confirm the valid strings by reading existing payments (GET /accounting/bill-payments), then hardcode the one that matches how the customer settles.