Reconcile corporate cards by connecting the issuer's posted transactions to the intended accounting records, employee evidence and eventual card settlement. Decide which system creates each expense before importing data. The same purchase can appear in a card feed, an employee claim and an AP platform without representing three separate costs.
This guide addresses completeness, duplicate prevention and clearing of corporate-card activity. It is distinct from designing expense approvals generally. Card liability, personal expenses, tax and period-end adjustments require your accountant's approved policy.
Identify whether the company or employee is liable for each card, which legal entity owns the account and how the issuer groups individual cards on statements. Record the source currency, settlement currency and relevant GL or clearing accounts.
List every data route: issuer feed, expense platform, employee report, manual card charge and AP bill payment. For each route, state whether it creates a posting transaction, supplies supporting evidence or imports data for matching.
This ownership map prevents a common design mistake: treating all available feeds as transaction-creation sources. A reconciliation import may need to match an existing expense rather than create another one.
Oracle's Bank Data Import guidance separates bank or credit-card data used for reconciliation from corporate-card expense data used for expense reporting. The latter appears in Imported Employee Expenses for use in expense reports.
That distinction should be reflected in the implementation. Document which format profile and connector serve each purpose, and how their records relate to the same issuer transaction.
Do not assume that a transaction visible in an imported-expense list has already produced the final GL entry. Likewise, a matched bank line does not prove that the business purpose or employee receipt has been approved.
Use the issuer transaction identifier where available, along with card account, posted date, merchant, amount and currency. Map it to the expense report, card charge or other approved posting record.
Retain authorization date separately where it differs from posting date. A pending authorization and a final posted charge should not automatically be treated as two purchases. Use the source's documented identifiers and status behavior rather than matching only by merchant and amount.
For aggregated statements, reconcile both individual-card totals and the consolidated issuer balance. Explain fees, refunds, adjustments and settlement payments separately. Net totals can conceal a missing charge offset by a missing refund.
Oracle's imported expense report documentation describes adding Ready expenses to reports and manually resolving unmatched employees. It points to cardholder-name or employee-ID alignment as an investigation area.
Maintain a controlled map of cards to employees, including issue and retirement dates. Names can change, be abbreviated or repeat across staff. Reissued cards may create new identifiers without a new employee.
Define ownership for unassigned transactions. A departed employee's card activity should remain visible to an authorized manager or finance owner. Do not leave it outside the reconciliation because no active employee receives the reminder.
An employee pays 860 for a hotel using a company card. The issuer feed imports the posted charge, while the employee manually adds the same receipt to an expense report as reimbursable cash expenditure.
Without an ownership check, the business could record the expense twice and reimburse the employee for a cost already borne by the company. The reviewer compares the card transaction, receipt and report, then uses the approved correction process to retain one expense and the appropriate liability.
If the hotel later refunds 120, that refund should link to the same purchase history. It should not be ignored because the original expense report is already approved. This hypothetical case illustrates reconciliation requirements, not a universal NetSuite posting sequence.
The issuer proves that a charge posted to the account. The receipt and business-purpose evidence support coding and policy review. The manager approves the expense under the organization's authority rules. These pieces answer different questions.
Define the treatment of missing receipts and personal charges with finance. An unresolved receipt should remain in an exception queue, while the liability and period cutoff still require appropriate accounting treatment. Do not omit real posted charges merely to make an approval report appear clean.
If a staff member must repay a personal charge, track that recovery separately. A promise to reimburse the company is not bank evidence. Retain the approved receivable or payroll treatment without inventing a generic journal recipe.
Start with the issuer's opening balance, add posted charges and fees, deduct credits and payments, and explain the closing balance. Tie the same period and currency scope to the relevant ledger accounts.
The payment to the card issuer generally settles an existing obligation in the designed accounting model; check that bank-feed classification does not create the expense again. Confirm the actual GL impact with the controller.
Review payments in transit, statement cut-off differences and foreign-currency settlement effects. A bank debit on one date and issuer credit on another may be legitimate timing, but should remain supported until both sides appear.
A merchant refund can arrive after the original expense has been posted and the card statement paid. Link it to the original purchase and determine the approved account, employee and project treatment.
A disputed charge may remain on the statement while the issuer investigates. Track the case outcome and avoid assuming that a provisional credit is final. Follow the issuer's records and your accounting policy for any later reversal.
Keep the case owner and next review date visible. The finance team should know whether it is waiting for employee evidence, merchant action, issuer investigation or a system correction.
Test an ordinary charge, split expense, merchant refund, duplicate manual claim, unmatched employee, reissued card and late-posted transaction. Include a card settlement arriving through the bank feed.
For each scenario, prove one intended expense, the correct liability or clearing movement and a traceable link to issuer evidence. Test that retrying an import or reconnecting a feed does not create duplicate postings.
For expense-platform mapping and card-feed ownership, CuriousRubik's NetSuite integration services can help review the complete source-to-ledger path. Bring issuer samples with unnecessary personal and payment details removed.
Oracle distinguishes reconciliation data from corporate-card expense data. Confirm which purpose each feed serves and which process creates the final accounting record.
A posting integration and a manual employee claim may both create records for one card purchase. Define transaction ownership and match them using reliable source identifiers.
No. Keep posted issuer activity visible and apply the approved accounting and exception policy while the supporting evidence is obtained.
Validate the designed accounting model. In a typical liability-settlement flow, the underlying expenses already exist; classifying the bank payment as new expense could duplicate them.
Assign an authorized finance or manager owner, verify card status and retain the transaction evidence. Inactive employee status should not make the charges disappear from review.