Who provides outsourced invoice-matching services, and what does having a provider perform AP invoice matching involve?

Who performs invoice matching as an outside service?

Three kinds of provider take on this work, and the difference that matters for control is where the matching runs:

A firm that already keeps your books may hold broad access. Intuit's help page on inviting accountant users to QuickBooks Online says those users have tools to review your books and make corrections, which is far more than matching needs. The page does not say what those tools exclude, so run matching through a named login whose role passes the test below, not the accountant access. Keep vendor changes and payment release with your own staff, and review the firm's users in the audit log every cycle.

Settle the delivery model first. A provider working in your system needs a role you restrict. A provider working on its own platform holds copies of your records, so you must reconcile its results into your ledger and be able to recover everything at exit.

What work moves to the provider, and what comes back?

How to run the matching comparison is a separate topic; the engagement concerns what crosses the boundary. Write each flow into the contract:

• Inputs. The provider receives supplier invoices from the channel you route to it, open purchase orders, receiving records, the vendor list without bank details, and your written tolerances and coding rules.
• Work. It captures invoice data, pairs each invoice with its order and receipt, compares them within tolerance, applies your coding rules, and flags duplicates and any invoice announcing new payment details.
• Outputs. It returns a matched set ready for approval, a held list, an exception list giving each item's reason, documents and owner, and a cycle summary reconciling documents received with documents returned.

Which decisions stay with the business?

Handing over the work does not hand over responsibility for the records. IRS Rev. Proc. 98-25 says that using a third party, such as a service bureau, for custodial or management services over your machine-sensible records does not relieve you of your recordkeeping obligations and responsibilities.

Decide first who releases a matched invoice for payment:

• The provider prepares and you approve. The provider marks matches ready, and your approver approves each invoice before payment. This is the stronger control and needs the least provider access.
• The provider clears within tolerance. The provider clears in-tolerance matches and escalates the rest. Your written tolerances then act as your approval, so set them yourself and review a sample of cleared items every cycle.

In both, your own people release every payment. This checklist places each task of the cycle on one side:

What must be ready before the first cycle?

A provider executes a process; it cannot invent one. If these are not written down first, the provider will return exceptions nobody can interpret:

• Tolerances. Set price and quantity limits, by vendor or category where they differ, and say what happens just outside them.
• Coding rules. Assign the account and class for each recurring purchase type, and name who decides items the rules do not cover.
• Vendor master. Keep one record per vendor. AccountingTools' guide to cleaning the vendor master file says to look for duplicate names that indicate duplicate records and to check key fields, such as taxpayer identification numbers, for missing information.
• Document routing. Fix one inbox or portal for invoices, how orders and receipts reach the provider, and a cut-off for each cycle.
• Spend without orders. Write a rule for invoices with no purchase order or receipt, as described below.

How should exceptions come back and be resolved?

Matching produces exceptions by design, so the scope must define the loop in order:

1. The provider returns each exception within an agreed time, with its reason, the documents and the owner it is routed to.
2. The named owner decides: the buyer on price, the receiver on quantity, the payables lead on coding.
3. The owner records the decision where the provider can see it, and the provider re-runs the match and closes or escalates the item.
4. Anything open past an agreed age goes to a named manager, and nothing held is paid.

Plan for items nobody touches. Check the exception list's aging every cycle.

How do you keep the provider away from payments and vendor bank details?

Access granted for matching could also create or pay a payable, so keep it narrow. The FTC's small-business cybersecurity guidance on vendor security says to limit access "to a need-to-know basis, and only for the time the vendor needs to do the job."

Intuit's help for QuickBooks Online shows how far preset roles reach and where you can narrow them:

• Intuit's user roles page describes the Accounts Payable Manager role as able to "see and do everything with expenses, vendors, and accounts payable (A/P) reports".
• Intuit's page on roles for paying bills says the QuickBooks Bill Pay role Bill clerk "can add bills, mark bills as paid, and add and edit vendors", so it fails the test below.
• Intuit's custom roles page, which covers QuickBooks Online Advanced and Intuit Enterprise Suite, lets you set each area's permissions to levels such as view only, create, edit, delete and approve.

Whatever the platform, the role you assign must allow no adding or editing of vendors, no bill payment, no marking bills paid, no banking and no user management. If your plan offers no role that passes that test, keep the provider out of your ledger: let it work on its own platform from documents and exports, and have your staff post the results. Give each person at the provider a separate login so the audit trail shows who did what.

Intuit's audit log page says a connected third-party app's data and changes appear as System Administration events, so a provider's integration leaves no named person in the log. Before connecting one, get in writing what it can create or change. Accept none that can add or edit vendors or pay bills, review its System Administration events every cycle, and disconnect it the day the engagement ends.

Vendor bank details need their own guard:

• The provider routes and never acts. Any invoice, letter or email announcing new bank details, a new remit-to address or new contact details comes to you unmatched.
• Verify on a number you already held. The FBI's Internet Crime Complaint Center advises using "secondary channels and/or two-factor authentication to verify requests for changes in account information", and the FTC's guidance says to call "a number you know to be correct, not the number in the email or text". Take that number from a record that predates the request, and if the vendor's phone or email changed recently, verify that change the same way first, or your callback may reach the fraudster.
• Call back on every change request. If one person both changes vendor details and releases payments, never skip the callback: the provider's flag catches only requests that reach the provider, so every change request, however it arrives, gets the callback before anything is changed.

Each cycle, check under Manage users that every provider login still has the role you assigned. Have an admin filter the audit log by each provider user for vendor edits, bill payments or settings changes, and resolve anything found before the next payment run. Remove access the day the engagement ends and whenever the provider's staff change, and close any document forwarding or shared folders it used. Intuit's Add and manage users page says that after you delete a user, "you can still view their history in the audit log".

What evidence shows the control operated?

The provider now runs part of your control, so you must be able to show it ran. Keep these for every cycle:

• Cycle summary. It shows documents received, matched, held and excepted, reconciled to what you sent.
• Exception log. It records each item's reason, owner, decision and closing date.
• Approvals and releases. Your own people record them in your own system.
• Change history. Intuit's audit log page says the log records edits to vendors and the user who made each change, and that "Events recorded in the audit log are available for two years", so export what you must keep longer.
• Your own testing. AS 2601, the PCAOB auditing standard on how a company's auditor considers its use of a service organization, treats a user organization's independent reperformance of selected items and its reconciliation of output reports with source documents as controls an auditor can test. Reperform a sample of cleared matches and tie the provider's output to your invoices each cycle.

For independent assurance, ask whether the provider has a SOC 1 report, which the AICPA describes as an examination of controls at a service organization that are likely to be relevant to its customers' internal control over financial reporting. AS 2601 distinguishes a report on whether controls had been placed in operation as of a specific date from one that also tests whether they operated effectively during a specified period. Whatever the provider's SOC 1 report calls itself, ask for one that tests operating effectiveness, and check that its period covers the months the provider matched for you. AS 2601 also says the service auditor's report should be modified where controls at user organizations are needed to achieve the stated control objectives, and that those controls should be listed in the description of controls; run each one it assigns to you. If the provider has no such report, ask for an agreed-upon procedures report describing relevant tests of controls, which AS 2601 also names as evidence; failing both, rely on your own reperformance.

Who holds the records during the engagement and after it ends?

IRS Rev. Proc. 98-25 sets rules for machine-sensible records: data in electronic format intended for use by a computer, kept in an accounting or financial system. It excludes paper records converted to an electronic storage medium, such as scanned invoices, which it refers to Rev. Proc. 97-22. It applies to a business with assets of $10 million or more at the end of its tax year, and to a smaller one if any of several listed conditions exists, the first being that all or part of the information section 6001 requires is not in its hardcopy books and records but is available in machine-sensible records. Under it, records must be kept so long as their contents may become material to administering the tax laws: at least until the period of limitation for assessment, including extensions, expires for each tax year; some, such as fixed-asset records, should be kept longer. Records must also be made available to the IRS on request and capable of being processed, and the system must not be subject to any agreement, such as a contract or license, that would limit or restrict the IRS's access to it, wherever it is maintained.

Those rules, and your need to produce the scanned documents behind each match, become engagement terms:

• The matched sets, images, exception logs and audit trails are your records, including the provider's copies.
• You can export all of them in a usable format at any time, not only at exit.
• No clause limits access by you or by the IRS, and the provider produces records on request.
• On exit, the provider returns everything within an agreed period and confirms in writing what it deleted and what it kept.
• Your retention period, at least that long, governs, not the provider's.

How do you write the scope and measure performance?

A scope statement a provider can be held to covers these parts:

• Inputs. It lists document types, channels, cut-off times and expected volume per cycle.
• Rules. It attaches your tolerances, coding rules and treatment of spend without orders as documents you own.
• Outputs. It defines the matched set, held list, exception list and cycle summary, with format and delivery time.
• Exception routing. It names owners by exception type, response times on both sides and the escalation age.
• Measures. It sets turnaround from invoice receipt to result, exception rate by reason, the error rate in your reperformed sample and the backlog at cycle end, reported every cycle.
• Access and records. It states the role granted, what the role excludes, and the ownership, export and exit terms.

Tie remedies to the measures, and treat a rising error rate in your sample as a reason to narrow what the provider may clear.

What changes if some spend has no purchase order, or a bookkeeper already keeps your payables?

A provider can only match documents that exist. AccountingTools' three-way matching article notes that a business "might elect to only conduct a two-way match" against the purchase order, but warns that this does not compare receiving documentation, so there is a risk of paying "an invoice for an incorrectly-billed quantity". It also notes that matching can be made more efficient "by excluding small-dollar and recurring invoices from the matching requirement". So the scope must say what the provider does with spend that has no purchase order or no receiving record, such as checking it against a contract price, routing it for approval or only coding it, and which person in your business decides each item. Route any invoice with no receiving record to a named person in your business to confirm what was received before approval.

If an outside bookkeeper already keeps your payables, a second provider in the same ledger splits the control evidence and blurs who fixes what. Either add matching to the bookkeeper's engagement under its own written scope, through a login whose role passes the test above, not the firm's accountant access, or write both scopes so they do not overlap: one party matches, one named party resolves exceptions, one keeps the exception log, and neither holds rights it does not need.

When is delegating the matching worth it?

Delegation is worth pursuing when all of these hold:

• Invoice volume is steady and more than your staff can match on time.
• Most spend carries purchase orders and receiving records, so matches are mechanical.
• Tolerances, coding rules and document routing are already written.
• Someone in the business has time to resolve exceptions, approve, release payments and test samples.

These conditions argue against it:

• Most spend has no order or receipt, so there is little to match.
• The process is undocumented, so the provider would be standardizing a process nobody specified.
• Nobody in the business can own exceptions.
• Your platform cannot keep the provider away from vendor edits and payments, and the provider cannot work from its own platform.

Moving the whole payables function to a provider, rather than only matching, is a larger decision with its own terms.