Sage Intacct is unusual among mid-market accounting systems because of how it handles coding. Instead of encoding department, location and project into an ever-widening account string, it keeps a short chart of accounts and attaches dimensions to each transaction line. That design is the reason Intacct reports well, and it is also the thing automation has to get right, because a bill posted without its dimensions is a bill that vanishes from every report anyone actually reads.
Reads digital PDFs, scans and phone photos. Exports to Excel, CSV and JSON.
Compare the extracted fields and line items against your own document.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
Intacct ships with a standard set of dimensions, entity, department, location, project, customer, vendor, employee, item and class, and supports user-defined dimensions on top of those. Each AP bill line can carry values across them.
The consequence is that "coding a bill" in Intacct is not one decision. An account code plus four or five dimension values is normal, and each of those values is a separate lookup against separate master data with its own validity rules. A line coded to the right account with the wrong department is wrong in a way that only surfaces at month end when a department head queries their numbers.
Dimension relationships add a further constraint. Intacct can restrict which departments are valid for an entity, or which projects belong to which customer. Automation that proposes combinations without respecting those relationships produces bills that fail on submission, so the master data has to be read and honoured rather than assumed.
Almost none of this is on the invoice. A supplier knows what they sold you and what it costs. They do not know which department owns it, which project it belongs to, or which entity is being billed unless someone told them at the point of ordering.
Reliable sources are, in descending order of usefulness: the purchase order or requisition, if you order against them, since dimensions were decided at commitment time; a per-vendor default, which handles recurring spend such as rent, utilities and software; the submitter or approver, where a departmental owner forwards their own bills; and an explicit reference the supplier prints because you asked them to.
What automation should not do is fill dimensions with a default value to make a bill post. A bill coded to a catch-all department is worse than a bill sitting in an exception queue, because the first one looks finished. If a required dimension cannot be determined, holding the bill is the correct behavior.
Intacct's multi-entity handling is a common reason organizations choose it, and it is the part of the model automation most often gets wrong.
Entity determines which vendors, dimensions and periods are available, and whether a transaction is a top-level or entity-level posting. Where shared vendors are enabled, one vendor record serves several entities, which simplifies master data but makes entity determination entirely a routing question rather than a lookup. Where entities have their own vendor records, resolving the supplier and resolving the entity become one combined decision.
Inter-entity transactions add another layer. A bill paid centrally on behalf of a subsidiary generates due to/due from entries according to your inter-entity configuration. That configuration belongs in Intacct and should stay there. Automation should identify the correct entity and let Intacct produce the inter-entity postings, not attempt to construct them externally.
The practical solution is the same as elsewhere: make entity determinable at intake, whether through per-entity email addresses, purchase order references, or the bill-to entity printed on the document. Determining it after the fact is guesswork with consolidation consequences.
Intacct distinguishes the AP bill from the AP adjustment, and using them interchangeably makes vendor histories hard to read.
An AP bill records an obligation to a supplier: the invoice they sent, with its lines, dimensions, terms and due date. An AP adjustment modifies an existing payable. A credit memo, a debit memo, a correction to a bill that has already posted. Both hit the vendor account, but only bills represent invoices received.
This matters for automation because supplier credit notes are common and are genuinely different documents. A credit note captured and posted as a negative bill will balance, but it will not behave correctly in aged payables or in payment selection. Capturing the document type accurately, and creating the right object for it, is worth more than it sounds.
Payment is a separate step. A posted bill is not a paid bill, and the payment run in Intacct selects from open payables according to terms, discounts and your own criteria. Automation delivers accurate, approved bills into that pool; deciding what to pay and when stays a treasury decision.
Intacct has native AP approval, with rules that can key on amount, entity, department and vendor. If your approvers have Intacct access and the routing works, there is no strong reason to move approval elsewhere.
The case for approving in front of Intacct is the familiar one: budget holders who do not need a full accounting license, and approvers who want to see the invoice document alongside the coded lines rather than a set of fields. Approving first also means only approved, correctly dimensioned bills reach the ledger, which keeps the AP subledger clean.
The cost is visibility of what is in flight. If bills only post after approval, anything pending is invisible to someone looking at Intacct alone, which matters at period end. Either keep a reliable view of the pending queue for accruals, or post bills in a draft state and approve inside Intacct. What does not work is running both approval mechanisms and hoping they agree.
From rules rather than from the invoice, because suppliers do not know your dimension structure. Purchase orders carry dimensions decided at commitment, per-vendor defaults handle recurring spend, and the submitting department covers forwarded bills. Where a required dimension cannot be determined, the bill is held for a person rather than posted to a default value.
Yes, with entity treated as a routing decision made at intake rather than something read from the document. Per-entity intake addresses, purchase order references and the printed bill-to entity are the usual signals. Inter-entity postings remain Intacct's job, following your configuration.
A bill records an invoice received and the obligation it creates. An adjustment modifies an existing payable, which is how credit and debit memos are recorded. Capturing a supplier credit note as a negative bill balances arithmetically but behaves incorrectly in aged payables and payment selection.
Yes. Bills can be created for Intacct's native approval workflow to route by amount, entity, department or vendor. Approving in front of Intacct is worth considering when budget holders lack licences or when approvers need to see the invoice document rather than coded fields alone.
Through Intacct's web services with a dedicated web services user and a sender identity registered on the company, scoped to the AP and master data permissions actually needed. Using a named service user rather than a person's login keeps the audit trail readable and survives staff changes.
Line level, which is the point of the dimensions model. A single invoice can split across several departments or projects, with each line carrying its own values, and that is exactly the case where manual entry is slowest and most error-prone.
AP automation for NetSuite: creating vendor bill records, handling subsidiaries and multi-book accounting, deciding whether approvals live inside NetSuite, and three-way matching against NetSuite purchase orders.
Accounts payable automation that reads every supplier invoice, matches it to your purchase orders, routes it for approval and posts it to your ledger. See how AP automation works end to end.
Design an accounts payable approval workflow that clears invoices instead of stalling them: routing rules, thresholds, delegation, escalation and a defensible audit trail.
What accounts payable software should do, how it differs from your accounting system, and the questions worth asking before you buy. A practical buyer’s guide.
Invoice processing software for teams handling steady invoice volume: automatic capture, validation rules, exception queues and clean export to your accounting system.
Upload a few of your least tidy supplier invoices and compare the extracted fields against the documents. That tells you more than any feature list.
