Almost every finance team we meet describes Sage Intacct accounts payable the same way before they have it: they want the paper to stop. Invoices arriving as email attachments, forwarded to whoever might know what they are for, printed for a signature, keyed into the ledger, then filed somewhere an auditor will ask about in nine months.
What actually changes on day one is narrower and more useful than “no more paper”. The bill still arrives. Somebody still decides it is legitimate. What changes is that the decision, the coding, the approval and the payment all happen in one place against one record, and that record is the same one the general ledger is reading from.
Key Takeaways
- AP automation removes the handoffs, not the judgement. Someone still approves each bill; they just do it from a queue instead of a paper tray.
- The bill and the ledger entry are the same object, so the payables figure on a dashboard reflects posted transactions as they land rather than waiting for a separate posting run. Bills still sitting in draft are not in that number, which is worth knowing before anyone treats the tile as a complete picture.
- Approval rules are configuration, not custom code. They can route by amount, entity, department, vendor or account, and they are the part most worth spending design time on.
- Your vendor master is the real migration work. Cleaning duplicates, terms and remittance details takes longer than configuring the module.
- Three-way matching between purchase order, receipt and invoice only works if purchasing is implemented alongside AP, not after it.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What Sage Intacct accounts payable automation actually replaces
AP automation software means moving invoice capture, coding, approval, posting and payment into one connected workflow instead of four disconnected ones. The saving is not in typing less, although you do type less. It is in eliminating the wait between steps, where an invoice sits in somebody’s inbox because nobody knows it is their turn.
That distinction matters when you build the business case. Data entry is a small share of AP cost in most organisations. Chasing is the large share: chasing the approver, chasing the coding, chasing the missing purchase order, then chasing the same invoice again when the vendor calls because it is overdue. A workflow with a visible queue and an owner at every step removes most of that, and it removes it immediately rather than gradually.
The bill record above is the centre of the whole module. It carries the vendor, the dates, the amounts, the dimension coding, the attachment of the original document, the approval history and the payment status. There is no separate AP subledger to reconcile back to the general ledger, because posting the bill is what creates the ledger entry. Teams coming from systems where the AP ledger and the GL are reconciled monthly usually take a week to believe this, and then spend the following week finding the reconciliation spreadsheets they no longer need. The attachment matters more than it looks, too: the scanned original travels with the record for the life of the transaction, which is what turns an audit sample request into a search rather than an afternoon in a filing room.
Real-time payables: why the number is current
Because bills post as they are approved rather than in a batch at period end, your payables balance is accurate at any moment. That sounds like a technicality. In practice it is the difference between a cash forecast built on what finance knows and one built on what the organisation has actually committed to.
The dashboard view is where this becomes visible to people outside finance. Vendor aging, the approval queue and payables against budget sit on one screen. A controller can see on a Monday morning which vendors are drifting past terms, what is waiting on somebody’s approval, and whether indirect spend is tracking. None of those questions require a report to be run.
There is a second effect that surprises finance teams. When commitments become visible in real time, the conversation about cash changes upstream. Budget owners see their own committed spend rather than their invoiced spend, and the “I forgot about that order” surprise at month end gets much rarer. For organisations running several entities, that visibility consolidates without a separate roll-up step, which is a large part of why consolidating and automating multi-entity finances tends to pay back fastest here.
Staying in control: approvals, separation of duties and the audit trail
Control in AP comes from three things: rules about who can approve what, enforced separation between the person who enters a bill and the person who releases the payment, and a trail that records every state change with a name and a timestamp. All three are configuration rather than custom development.
Approval rules are where the design effort belongs. They can route on amount thresholds, entity, department, vendor, expense account or combinations of those, and they can escalate. The common mistake is to encode the current org chart in full detail, including the two exceptions for people who are about to change roles. Build the rules around positions and thresholds instead, keep the matrix short enough that a new controller can read it in ten minutes, and accept that a handful of edge cases will route to a human queue.
Separation of duties is the control auditors ask about first, and it is worth getting explicit early. In a small team it usually means the AP clerk enters and codes, a budget owner approves, and a second finance signatory releases payment. In a very small team it means being honest that one of those roles is covered by review rather than by system separation, and documenting that decision rather than hoping nobody asks.
The audit trail is the quiet win. Every bill carries who entered it, who approved it, when, at what value, and the original document as an attachment. Audit requests that used to mean pulling files become a search. That is not a headline feature but it is one of the first things clients mention a year in.
Payment management: how money actually leaves
Payments run from the same records, in batches you select by due date, vendor, entity or discount opportunity. You can pay by check, ACH, or through a card programme, and the payment posts back against the bill automatically so nothing needs matching afterward.
Card payment programmes deserve a specific note because they change the economics rather than the workflow. Paying eligible vendors by virtual card can turn a cost centre into a rebate, and the integration means the payment still originates from the same batch run. Whether it is worth it depends entirely on your vendor mix, and that is a spreadsheet exercise worth doing before go-live rather than a year later.
The practical decision most teams underestimate is payment run cadence. Moving from “we pay when someone asks” to a fixed weekly or twice-monthly run is a policy change, not a software change, and it is the single largest source of early friction with vendors and budget owners. Decide it during design, communicate it before go-live, and hold it.
What the first month after go-live actually looks like
Week one is slower than your old process. That is normal and worth planning for. Approvers are learning a queue, the AP team is checking the workflow did what they expected, and everyone is more careful than they will be in week four. Expect a temporary dip, not an immediate saving.
By the second or third payment run, the shape changes. Invoices stop going missing because they are in a queue with an owner rather than an inbox. The chasing that consumed AP time moves to the system, which sends the reminders. Month end gets quieter because there is no scramble to find and accrue unposted invoices; they are already posted or already visible as pending.
[DATA: Lucentive’s typical invoice processing time before and after AP automation across recent implementations — Rich to confirm]
The honest trade-offs: approvers who ignored paper will also ignore a queue, so somebody has to own escalation. Vendors with unusual billing arrangements still need manual handling. And automation exposes process gaps that were previously absorbed by a person, which feels like the system creating problems when it is really the system surfacing them.
Where AP implementations get stuck
Four things account for most of the delay in AP projects, and only one of them is configuration. The rest are data, decisions and organisational habits that surface once the workflow is real. Naming them early in the project plan is usually enough to stop them becoming the reason a go-live date slips.
The vendor master
This is the work. Duplicate vendors, stale remittance details, terms that were agreed verbally and never recorded, and W-9 status that nobody has checked. Cleaning it is unglamorous, it cannot be automated meaningfully, and it should start weeks before configuration does. Budget real internal hours for it.
Open invoices at cutover
Decide early whether unpaid invoices are migrated as open bills or paid down in the legacy system. Both are defensible. What causes pain is deciding late, because it changes the cutover plan and the first bank reconciliation.
Expecting document capture to be perfect
Automated capture reads well-structured invoices well and unusual ones poorly. Plan for a review step permanently rather than treating exceptions as a defect to be fixed later.
Implementing AP without purchasing
If you want three-way matching between order, receipt and invoice, purchasing has to be in scope at the same time. Retrofitting purchase orders onto a live AP process means re-training the same people twice. Our companion piece on purchase order approvals covers how that chain is designed, and there is a broader case for it in the benefits of a purchase order system.
Summary
Accounts payable is usually the first module where a finance team feels the implementation was worth it, because the pain it removes is daily and visible. The value comes from the workflow design rather than the software: a short approval matrix, a clean vendor master, a fixed payment cadence, and purchasing in scope alongside it.
[DATA: Lucentive’s typical implementation timeline for the accounts payable module — Rich to confirm]
The page this replaces also ran a Sage customer video. Those are worth ten minutes if you watch them with a filter: listen for the shape of the change, meaning what the controller stopped doing and which step the approval queue replaced, and skip the numbers, because they describe that organisation’s process rather than yours.
The old version of this page offered a white paper, an analyst report, a datasheet and an infographic behind a form. Those describe what the module does. They cannot tell you whether your approval matrix will survive contact with your organisation. If you want to see it working against your own invoices rather than a demo dataset, talk to our team and we will walk through your current AP process step by step. You can also read our earlier take on why automating accounts payable is worth doing.
Frequently Asked Questions
What does accounts payable automation software actually mean?
It means invoice capture, coding, approval routing, posting and payment happen in one connected workflow rather than four separate ones with manual handoffs between them. The measurable gain is usually not fewer keystrokes but less waiting, because every invoice sits in a queue with a named owner instead of an inbox. Judgement stays human; the movement between steps stops being manual.
Is the Sage Intacct accounts payable module separate, or part of core financials?
Accounts payable is a distinct module that sits directly on the general ledger, so bills post without a subledger reconciliation. It is commonly licensed as part of the core financial set alongside the general ledger, cash management and accounts receivable. Purchasing, which adds requisitions, purchase orders and three-way matching, is a separate module and a separate implementation decision.
How does three-way matching work?
Three-way matching compares the purchase order, the goods or services receipt, and the vendor invoice, and flags any of the three that disagree on quantity or price. It requires the purchasing module, because two of the three documents originate there. Tolerances are configurable, which matters in practice: a matching rule with no tolerance will route almost every freight charge to a human.
Can we automate accounts receivable at the same time?
Yes, and many teams do, but sequencing them together doubles the change your finance staff absorb in one go. If AP is the bigger pain, lead with AP and follow with receivables a quarter later. If cash collection is the pressing problem, reverse it. What rarely works well is running both design phases in parallel with the same three people.
Does this work for job-costed businesses such as construction?
It works well, provided the job or project dimension is designed before the first invoice is coded. Job-costed organisations need committed cost visibility, which means purchasing has to be in scope so that orders show against the job before the invoice arrives. Retention, progress billing and change orders need explicit design decisions rather than default settings.
What training do AP clerks need?
Less than most people expect for the daily entry and payment work, which is usually a day of hands-on practice. The training that matters is for approvers, who use the system infrequently and therefore forget it, and for whoever owns the approval matrix and vendor master. Budget more time for approver communication than for AP team training.