Exporting Card Spend to Sage Intacct: Cash Management vs. AP, Which and Why

Sage Intacct will accept your corporate card spend two different ways, and most teams pick one by accident — whoever set up the card five years ago chose, and nobody revisited it. The two routes produce different journal entries, different reports, and very different month-end work. Here is what each one actually is, and how to choose deliberately.

Route 1: Cash Management charge card transactions

This is the purpose-built path. Intacct's credit card transaction page in Cash Management records a charge directly against the credit card account, debiting expense and crediting the card liability.

Two properties matter. First, a vendor is optional. Intacct's documentation describes this route as the one to use "when you have small charges to enter quickly, or when you do not have a vendor invoice entered in Intacct" — which is an accurate description of nearly all swipe spend. Second, dimensions are set per line. The underlying CCTRANSACTION object carries a full dimension set on every distribution line: GL account, department, location, project, task, class, customer, vendor, employee, item, warehouse, contract. A single $400 charge can split across three projects with different departments on each line.

Route 2: Accounts Payable, with the card as the payment method

The AP route treats the charge as a vendor bill that happens to be paid by card. You enter the bill, you pay it on the Pay Bills page selecting the card as the payment method, and Intacct books the whole thing through the AP subledger.

This is the correct mechanism for invoice-backed vendor spend. A vendor is required — that is the point of the route, not a limitation of it. You get the bill, the AP aging while it is open, the vendor spend history, and the approval path your AP workflow already enforces.

Where it goes wrong is when teams force swipe spend into it. A coffee run does not have an invoice, and inventing a vendor record for every merchant your employees touch produces a vendor master nobody can maintain and a bill approval queue full of $14 items.

The bridge people forget: charge payoffs

The two routes are not actually a fork. They meet at the payoff.

When the statement comes due, Cash Management's charge payoff moves the liability into AP: it creates a bill you pay on the Pay Bills page, and once that bill is paid, the underlying card transactions are marked as paid. The credit card account setup requires a vendor ID precisely for this — the vendor on the card is the card issuer, not the merchant.

So the real shape is: individual charges live in Cash Management with merchant-level detail and full dimension coding; the monthly payoff lives in AP as one bill to the card issuer. Each subledger does the job it is good at. Teams that route every charge through AP are collapsing that structure and paying for it in vendor-master sprawl.

The 1099 argument, and why it is wrong

The most common reason given for pushing card spend through AP is 1099 tracking: "we need a vendor on it or we can't report." That reason does not hold.

The IRS instructions for Forms 1099-MISC and 1099-NEC state that payments made with a credit card or payment card — along with third-party network transactions — are reported on Form 1099-K by the payment settlement entity under section 6050W, and are not subject to reporting on 1099-MISC or 1099-NEC. The card network already reports it. Putting the merchant on an Intacct bill does not create an obligation, and in fact the risk runs the other way: card payments swept into your 1099 vendor totals can produce double-reporting you then have to unwind.

There are good reasons to want vendors on card spend — vendor spend analysis, contract and subscription tracking, negotiating leverage. Use the vendorid field on the charge card transaction line for those. It is there, it does not require an AP bill, and it keeps the liability where it belongs.

Choosing

Spend type	Route	Why
Employee swipes, subscriptions, ad spend	Cash Management charge card transaction	No invoice exists; dimension coding per line; no vendor master pollution
Invoice-backed vendor bills paid by card	AP bill, card as payment method	The invoice and approval path already exist
The monthly statement payment	Charge payoff → AP bill to the issuer	Moves liability to AP once, not per charge
Merchant refunds and credits	Cash Management, negative line	Books a credit against the same GL the charge hit

What this means for an integration

If you are evaluating a tool that posts card spend to Intacct, ask which object it writes. "Integrates with Sage Intacct" covers products that create bank feed lines, products that push journal entries, and products that write proper charge card transactions — and those are not the same outcome. A journal entry loses the subledger. A bank feed line arrives uncoded.

Summit Spend takes the Cash Management route: transactions post as CCTRANSACTION records against the mapped charge card, with GL account, department, location, project, class, customer, item, and vendor set on each line, the receipt attached to the Intacct record, and the card's own payoff left to Sage's charge payoff process rather than being re-created as a bill. Level 3 line detail, where the card provides it, expands into separate distribution lines so a single mixed charge posts split rather than lumped.

The mechanism is not exotic — it is the one Intacct designed for this. The work is in getting every line coded before it posts, which is where the month actually goes.