Sage Intacct and Fishbowl integration

What moves between them

Vendor master records and GL accounts flow from Sage Intacct into Fishbowl Advanced on a recurring schedule. Vendor names, numbers, and tax IDs from Intacct are upserted into Fishbowl so every purchase order can reference a valid vendor. GL account structures and dimension hierarchies from Intacct are mapped into Fishbowl's cost allocation fields so procurement and manufacturing orders carry valid cost centers. Data moves in one direction; Fishbowl does not write back to Intacct accounting.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Sage Intacct side, it calls getAPISession once to obtain a sessionid, caches it for 50 minutes, and automatically refreshes it on the next call after expiry. The XML body of every response is parsed for error messages and status codes, since HTTP 200 does not indicate success. For Fishbowl, ml-connector posts to /api/login once per job, receives a session UUID token, and passes it in the Authorization: Bearer header on all subsequent requests. Since Fishbowl runs on customer-provided hardware, the connector accepts the full server URL and port from your Fishbowl instance, validates the hostname and connectivity, and detects any changes in the URL before starting a sync. Both systems are pull-only, so ml-connector runs on a fixed schedule you define, and it handles retries on transient failures. Every vendor and GL account record carries an audit trail so you can see when it was read, how it was mapped, and whether the downstream write to Fishbowl succeeded.

A real-world example

A mid-sized discrete manufacturer runs Sage Intacct for accounting and financial reporting, and Fishbowl Advanced on-premise for procurement and inventory. Before the integration, the procurement team manually maintained a vendor master list in Fishbowl that drifted from the approved vendors in Intacct, and purchase orders often referenced GL accounts that had been retired or reorganized. Cost allocation reports disagreed between the two systems. With Sage Intacct and Fishbowl connected, vendors and GL accounts sync on a weekly schedule before the procurement team starts purchasing, so the vendor list is always current, and cost allocation is consistent across purchase orders and accounting reports.

What you can do

• •Sync vendor master records from Sage Intacct into Fishbowl so every purchase order references a valid approved vendor.
• •Map GL accounts and dimensions from Sage Intacct to Fishbowl cost allocation fields for consistent cost center reporting.
• •Manage Sage Intacct session caching and automatic refresh so a 50-minute session expiry does not interrupt sync.
• •Poll both systems on a schedule that fits your procurement calendar, with automatic retry on transient failures.
• •Maintain a complete audit trail of every vendor and account record, including when it was read and whether the downstream write succeeded.

Questions

Which direction does data flow between Sage Intacct and Fishbowl?

Vendor master records and GL accounts flow from Sage Intacct into Fishbowl Advanced. Every vendor in Fishbowl is validated against the approved vendor list in Sage Intacct, and cost allocation in purchase orders is mapped to GL accounts maintained in Intacct. Fishbowl does not write back to Intacct, since Fishbowl is procurement and Intacct is the source of truth for accounting.

How does ml-connector handle Sage Intacct's session-based XML authentication?

ml-connector calls Sage Intacct's getAPISession once per sync run using your senderId, senderPassword, companyId, userId, and userPassword, and caches the resulting sessionid for 50 minutes. It automatically refreshes the session on the next call after expiry. All responses from Intacct are HTTP 200, so ml-connector parses the XML body for error messages and status codes to determine success or failure.

Does Fishbowl's on-premise architecture require special handling?

Yes. Since Fishbowl runs on a customer-provided server at a custom hostname and port, ml-connector accepts the full server URL from your instance, validates hostname resolution and connectivity before each sync, and detects changes in the URL so network moves do not go unnoticed. All requests carry a bearer token obtained by posting to /api/login.