Business credit cards on ScotiaConnect

The commercial card program on ScotiaConnect sits alongside the operating-account and payment screens, so AP teams can treat card spend as a first-class payable instead of a separate system. Purchasing cards replace small-ticket invoices, corporate cards cover travel and expense, and fleet cards route fuel and maintenance spend. Each program has its own statement cadence, its own reconciliation flow and its own spend-control hierarchy. This reference walks through how card statements are retrieved, how MCC coding drives control policy, and how individual and central billing models shape AP workflow.

Short version. ScotiaConnect hosts purchasing, corporate and fleet card programs, delivering daily transaction data, MCC-driven controls, reconciliation to GL and cost centre, and CSV or ERP-ready exports at statement close.

Purchasing, corporate and fleet cards

Card program basics

Purchasing cards are for AP-driven supplier spend. Corporate cards are for travel and expense. Fleet cards focus on fuel and maintenance. Each product carries different acceptance, different controls and different statement cadences.

A purchasing card is designed to replace the paper-invoice loop for small and mid-sized supplier purchases. Instead of cutting a cheque or a wire for every under-thousand-dollar supplier item, the AP team assigns a purchasing card to a responsible buyer, sets a monthly limit and a category list, and consolidates the spend into a single central-bill statement. Inside ScotiaConnect, purchasing-card activity appears in the cards ledger with merchant name, MCC, amount and value date, and the reconciliation workflow lets the AP reviewer assign a GL code and a cost centre per line.

Corporate cards are the travel and expense instrument. Cardholders are individual employees, and the card is embossed with the employee's name. Most clients operate corporate cards on an individual-billing model, where the employee pays the statement and claims reimbursement through expense software; some clients use central billing for seniority or regulated reasons. ScotiaConnect supports both and exposes the billing model on the card-detail screen.

Fleet cards sit between the two. Acceptance is narrowed to fuel stations, maintenance shops and fleet-relevant merchants, and the MCC control list is pre-populated to block non-fleet categories. Yellowpine Equipment Rental, for example, issues fleet cards per vehicle rather than per driver; this keeps the audit trail cleaner for depreciation and maintenance allocation, and the cards ledger inside ScotiaConnect reports spend by vehicle unit rather than by employee.

Statement retrieval and online reconciliation

Short version. Transactions post daily to the cards ledger. Cardholders or AP reviewers code each line to a GL account and a cost centre. The reconciled data exports at statement close as CSV or a pre-formatted ERP import file.

Card transactions post to ScotiaConnect daily. Each item carries the merchant descriptor, the MCC assigned by the acquiring card network, the transaction amount, the posted date and the cardholder reference. The reconciliation screen lets a cardholder or a central AP reviewer click into each line, confirm the purpose of the spend, assign a GL account from the company's coded list, and assign a cost centre. Approval rules can require review by a line manager before the statement closes, and any line not coded by the close date is routed to a default clearing account for later reclassification.

At statement close, the reconciled data exports in two common shapes. The first is a CSV file that most accounting teams import into their own clearing-and-coding spreadsheet. The second is a pre-formatted ERP import file, generated against templates for SAP, Oracle, NetSuite and several mid-market packages. Tallstone Cement Group runs its purchasing-card close in a single afternoon: transactions are pre-coded across the month, the reviewer signs off the queue, the ERP import file generates, and the cash settlement posts against the central-bill account in the operating-account view the following business day.

Statement PDFs continue to be produced, primarily for audit evidence. The PDF includes per-card summary totals, merchant and MCC breakdown, and a signature line that is still required in a small number of regulated segments. Statement archival follows the same seven-year retention window as operating-account statements.

MCC coding and spend-control hierarchy

MCC is the merchant-category code that the card network assigns at the point of sale. It identifies the merchant's business - airlines, restaurants, office supplies, fuel stations, hotels - in a four-digit code that is consistent across the network. ScotiaConnect uses MCC ranges to enforce spend controls. A purchasing-card program might allow MCCs associated with office supplies, logistics and software subscriptions, while blocking MCCs associated with travel or entertainment; a corporate card would invert that logic.

The spend-control hierarchy stacks three layers. The card-level limit caps the card's single-cycle spend. The MCC list determines which merchant types are accepted. The transaction-level rule can route individual transactions above a threshold to an approval queue before the merchant is paid. Combined, these controls let the program administrator draw tight policy boundaries without forcing manual approval on every swipe. Guidance from the Office of the Superintendent of Financial Institutions through OSFI frames the broader operational-risk expectation that commercial card programs remain inside an enforced spend policy.

A well-designed control hierarchy is light to operate. Most program administrators rebuild the MCC list once a year based on the previous year's actual spend, raise or lower card-level limits for underused or over-limit cards twice a year, and otherwise leave the policy in place. The daily workload is reconciliation, not rule configuration.

Card type, user, billing and statement cadence

Short version. Five card-type rows cover the commercial card configurations ScotiaConnect clients most commonly issue.
Card typeTypical userBilling modelStatement cadenceAcceptance scope
Purchasing cardAP-authorised buyerCentral billingMonthlyBroad, MCC-filtered
Corporate card (T&E)Individual employeeIndividual billingMonthlyTravel, hospitality, retail
Corporate card (central)Senior employeeCentral billingMonthlyTravel, hospitality, retail
Fleet cardVehicle or driverCentral billingBi-weeklyFuel, maintenance, tolls
Virtual single-use cardSpecific supplier invoiceCentral billingOn completionSingle-merchant, single-amount

How one AP lead describes the workflow

Short version. The value of the cards module is not the card itself; it is the MCC-driven control layer and the daily transaction feed that keeps coding fresh.

“We issue fleet cards per vehicle rather than per driver. ScotiaConnect shows the spend under each vehicle unit, which means maintenance cost allocation lines up with depreciation without a separate spreadsheet. The daily feed keeps coding current.”

— Aroha N. WainwrightFinance Controller, Yellowpine Equipment Rental

Frequently asked questions

Short version. Four questions that cover the decisions program administrators make when they stand up a commercial card layer on ScotiaConnect: card types, reconciliation, MCC coding and billing model.
What types of commercial cards does ScotiaConnect support?

ScotiaConnect supports purchasing cards for AP-driven spend, corporate cards for travel and expense, and fleet cards for fuel and maintenance. Each program sits in the cards section of the portal with its own statement cadence and its own reconciliation workflow.

Virtual single-use cards are also available for one-off supplier payments where a plastic card is neither practical nor safe. Single-use card numbers are generated for a specific merchant and a specific amount, and they expire once used.

How is card spend reconciled inside ScotiaConnect?

Transactions post daily to the cards ledger with merchant name, location, MCC and amount. Cardholders or AP reviewers assign GL codes and cost centres line-by-line, and the reconciled file exports at statement close as CSV or a pre-formatted ERP import.

Approval rules can require review by a line manager before the statement closes. Any line not coded by the close date is routed to a default clearing account for later reclassification.

What is MCC coding and why does it matter on a commercial card program?

MCC is the merchant-category code assigned by the card network at the point of sale. ScotiaConnect uses MCC ranges to enforce spend-control hierarchies, blocking categories entirely, capping weekly spend by category, or routing certain categories to a higher approval tier.

A typical program reviews the MCC list annually, based on the previous year's actual spend. Controls are then left in place; the daily workload is reconciliation and statement close, not rule configuration.

What is the difference between individual billing and central billing on a commercial card?

Individual billing issues each statement to the cardholder, who pays the card balance and then claims reimbursement through expense software. Central billing issues a single consolidated statement to the company, which pays directly against the operating account.

Purchasing cards nearly always use central billing. Corporate cards can run either model; the choice depends on expense-policy design, card-fee structure and the cash-flow impact of moving employee liability onto the company balance sheet.