SitewideOps is the operational subledger. Sage Intacct stays the general ledger of record. Bills, vendor credits, and summarized journal entries post into Intacct carrying the full dimension set, so your controller reconciles documents, not spreadsheets.
SitewideOps connects to Sage Intacct through its REST API and pushes three kinds of records: AP bills, vendor credits, and summarized journal entries for everything else the operational ledger books (labor, inventory movements, WIP adjustments, corrections). Every line carries Project/Job, Location, Department, Cost Code, and Cost Type, plus the vendor, customer, or employee, so Intacct receives records dimensioned the way your reports already read.
It does not touch your chart of accounts, does not create GL accounts, and does not rewrite anything already in Intacct. Your chart is imported into SitewideOps from Intacct, and every account a document posts to is mapped by you in Settings. There are no default account numbers in the product. A document that would post to an unmapped account fails with an error naming the setting to fix, rather than posting somewhere plausible.
The integration is designed around the things that go wrong between an operations system and a general ledger.
Project/Job, Location, Department, Cost Code, Cost Type, and the customer, vendor, or employee, posted per line the way Intacct dimensions them. Departments are trades, locations are branches, and the two are never combined into one code.
SitewideOps ships with no chart of accounts and no default posting rules. You import your Intacct chart, then map cost types and system roles (AP, GRNI, inventory, WIP, retainage, and so on) to accounts in Settings. The map is yours to change; the product never guesses.
Every GL-bound document carries an immutable posting reference. A retry after a network fault checks Intacct for the document before sending again, so a bill that already posted is never posted twice.
If Intacct rejects a post because the period is closed or the document number already exists, the record lands in a sync exception queue with two actions: post it into the next open period with a memo, or hold it until the period is reopened. Nothing retries in a loop.
Every push attempt is recorded, with the request, the response, and who triggered it, so a question about why a bill shows in Intacct on a given date has an answer without a support ticket.
Accounting periods in SitewideOps close and block further posting; reopening requires a recorded reason. Voids and reversals book on the current date, never into a closed month.
A versioned public REST API with an OpenAPI spec and scoped keys is live for anything the native connector does not cover, and for the other systems you run.
The sync is one direction, from SitewideOps into Intacct. It does not pull journals back, does not watch your general ledger for changes, and does not try to detect drift between the two systems. Your accountant owns the books; the integration gives them clean, dimensioned documents to own. Period close, month-end accruals, and financial statements happen in Intacct, on your schedule.
Also connects to QuickBooks Online. The same posting engine, exception queue, and audit log drive the QuickBooks Online integration. Tell us which system you run and we will walk through exactly how a bill moves from the job to your books on your demo.
A walkthrough on your own chart: dimensions, posting rules, and what the exception queue looks like when a period is closed.
Anyone interested gets a free 21-day demo account: the full product, every feature, no credit card.