Corporate Credit Card Statement to Excel by Cardholder

A multi-cardholder corporate card statement groups charges under per-cardholder section headers, so a plain PDF-to-CSV export severs the link between each transaction and the employee who made it. You end up with a column of dates, merchants, and amounts and no reliable way to say who spent what. The fix is to extract one row per transaction and carry the cardholder or employee name from each section header down onto every line beneath it, then add cost-center, accounting or GL-code, and last-4 columns wherever the statement provides them. With those columns in place, you can total and allocate the spend by employee, department, or GL code in Excel.

That is the whole job of converting a corporate credit card statement to Excel organized by cardholder, and it is a different job from the one most converters solve. The common tools take one card account and turn its transactions into columns. A company card program puts dozens of cardholders on a single statement, and the value is not in listing the charges, it is in attributing each charge to the right person and the right cost center. Lose the cardholder link and the spreadsheet is just a flat list no one can reconcile.

The work breaks into four parts: understanding how a multi-cardholder statement is laid out so you can see why a flat export fails, propagating the cardholder name onto every transaction row, capturing the corporate fields like cost center and GL code, and then running the same process across long statements and many months. The first move, header propagation, is the one that does most of the work, so it gets the most attention below. Throughout, treat amounts and currency as data to extract exactly as shown; totaling and any currency conversion happen in Excel afterward, not during extraction.

Why a Multi-Cardholder Statement Breaks a Standard PDF Export

A corporate card statement is built in layers. The first page or two is usually account-level: the company name, the billing period, a balance summary, and a roll-up of total spend. After that the statement breaks into per-cardholder sections. Each section opens with a header that names the cardholder or employee and shows a partial account number, typically the last four digits of their card. Below the header sit that person's detail transaction lines: the dates, merchants, and amounts they charged during the period. Then the next cardholder's header appears, and the pattern repeats, often across many pages, interleaved with summary recaps and the occasional marketing insert.

The cardholders below the primary account are supplementary or employee cardholders, individual cards issued under one company account. Each gets its own section and its own header. That header is the only place the statement states who the following charges belong to, which makes it the single most important piece of structure to preserve.

This is exactly what a naive conversion throws away. A flat PDF-to-CSV dump reads transaction lines as it finds them and treats the section header as just another line of text, or skips it as noise. The detail rows come through, but the name that sat above them does not travel with them. Run that on a statement with fifteen cardholders and you get a few hundred charges in a single undifferentiated list, every row stripped of the one attribute, the cardholder, that allocation depends on. The conversion technically worked and the result is still useless.

The reason this matters is that corporate card programs run at real scale, not as an edge case. The GSA SmartPay program statistics show that GSA SmartPay, described as the world's largest government charge card program, accounted for $39.4 billion in total program spend in fiscal year 2025. Programs that large, and the far smaller ones a typical bookkeeper handles, share the same monthly need: every charge has to find its way back to the person and the budget line that owns it. Per-cardholder attribution is the recurring problem, not a one-off.

It is worth separating this from converting a single card account, which is a simpler task. If you only have one card, a single statement with one stream of transactions, the path is more direct, and our guides on converting a single American Express account statement and Chase Ink Business card statement conversion cover it. The closest relative to the multi-cardholder job is an AmEx program with several cardmembers on one account, which we address in detail for AmEx Business Platinum multi-cardmember statements. What sets the multi-cardholder case apart is precisely the structure described above: the goal is a company card statement converted to Excel per employee, where each person's charges stay identifiable, rather than collapsed into one anonymous pile.

Attaching Each Cardholder's Name to Every Transaction Row

The move that turns a flat dump into attributable data is simple to state: produce one row per transaction, and on each row repeat the cardholder or employee name and the last-4 carried in the section header above that transaction. The header sits over a block of charges. Every charge in that block belongs to that person until the next header appears. So you treat the header not as a label to read once, but as a value to copy downward onto each line beneath it, restarting when a new cardholder section begins.

In practice that means targeting the detail sections and ignoring the rest. Summary totals, balance roll-ups, and recap tables list amounts too, but those are aggregates, not transactions, and pulling them in double-counts the spend. The instruction you want is: read the per-cardholder detail lines, carry the header's name and last-4 onto each one, and leave the summary figures alone.

This is straightforward to express as an extraction prompt. A workable pattern names the structure you want and the columns you need:

"This is a corporate card statement with separate sections for each cardholder. Create one row per transaction. Repeat the cardholder name and the last 4 digits of their card on every row. Columns: Date, Cardholder, Last4, Merchant, Amount, Currency. Skip summary and total pages."

Naming a field as a column makes it a column in the output, so the cardholder name lifted from the section header becomes a first-class field you can sort and filter on, not buried context. Adding a goal statement helps the extraction handle the messier statements: telling it you are attributing every charge to the employee who incurred it for expense allocation gives it the intent to resolve ambiguous layouts sensibly, rather than guessing field by field. That goal framing is what lets you split a corporate card statement by employee even when one cardholder's section runs onto a second page or a header is formatted differently from the rest.

The same approach is how our tool produces a company card statement as a spreadsheet by cardholder. The extraction interface is a single prompt field: you describe the structure you want in plain language and download the result as Excel, CSV, or JSON. The output controls documented for the product include exactly this shape of instruction, the canonical example being "Create one row for each line item, and repeat the 'Invoice Number' on each row." Applied to a corporate statement, you swap in the cardholder field: one row per transaction, repeat the cardholder name and last-4 on each row. The propagation move and the prompt that performs it are the same idea, written for the document in front of you.

When a transaction description carries extra detail, such as a hotel name, a flight route, or a vendor reference, extract the description as shown. Keep it intact in its column so the context is available later for review or categorization. Do not ask the extraction to shorten, summarize, or add up anything in the description; its job is to capture what is on the line, faithfully and in full.

Capturing Cost Center, GL Code, and Last-4 for Allocation

Once each row carries its cardholder, the next step is pulling the fields that let you code the spend. Commercial and business card statements often carry more than the basic date, merchant, and amount. Depending on the issuer and how the program is configured, a statement may print an employee or cardholder name, a cost center, an accounting or GL code, and the last four digits of the card. These are the fields that make a statement allocation-ready, because they map a charge not just to a person but to a budget line.

The catch is that they vary. One program prints cost centers against every transaction; another carries them only in the cardholder header; a third omits them entirely and expects you to assign codes yourself. So the goal is to extract these fields where they exist and leave the cell blank where they do not, rather than have the extraction stall or guess when a code is missing. To extract cardholder and GL code from a corporate card statement reliably, you ask for them as conditional columns: capture the value when the statement provides it, default to blank otherwise.

A prompt for this layers the field rules onto the propagation move from the previous step:

"Add a Cost Center column and a GL Code column. Populate them only where the statement shows a cost center or accounting code for the transaction; leave blank if not present. Carry the last 4 digits from the cardholder header onto every row alongside the cardholder name."

Field-level rules cover the common variations. You name the exact columns you want so the headers match your chart of accounts. You set a default, such as blank or zero, for when a code is absent. And where a code appears in a predictable spot, a hint helps: if the GL code always sits in brackets at the end of the description, say so, and the extraction can lift it cleanly instead of capturing the whole string. Our tool supports this kind of conditional and rule-based instruction directly, the documented controls including defaults like "If 'Tax Amount' is missing, set its value to 0," fallbacks for fields that appear in more than one place, and explicit column naming, so the cost-center and GL-code logic above is expressed in the same prompt that handles the cardholder propagation.

With cardholder, cost center, and GL code sitting as their own columns, the data is ready for whatever coding your books require. You can filter to one employee, pivot by cost center, or group by GL code before posting to your accounting software, all from a single sheet that already knows who spent what and against which budget.

Building a Spreadsheet Ready to Allocate by Employee, Department, or GL Code

The output you are aiming for is one sheet, one row per transaction, with the columns that matter already in place: cardholder or employee, last-4, merchant or description, amount, currency, and, where the statement carried them, cost center and GL code. That structure is what makes the data workable. Because every charge sits on its own row with its attributes beside it, you can sort, filter, pivot, or write a SUMIF yourself across any column without first untangling who spent what.

That is what lets you allocate company card spend by employee and department from the same file. Filter by cardholder to build a reimbursement or review list for one person. Pivot on cost center to roll spend up by department for a budget owner. Group by GL code to prepare the posting that goes into your accounting system. The same corporate card expense allocation spreadsheet feeds reimbursement, audit logging, GL posting, and month-end close, because each of those tasks is just a different cut of the same attributed rows.

One boundary is worth being precise about, because it is good practice rather than a shortcoming. Extract the amount and the currency exactly as they appear on the statement, then do the totaling, and any currency conversion, in Excel. A statement that mixes USD charges with a few foreign-currency transactions should come through with each amount and its currency intact; you apply your own rate and sum the columns in the spreadsheet, where you control the math and can show your working. Treating extraction as the step that captures the figures, and Excel as the step that computes on them, keeps the numbers auditable.

Travel and entertainment spend is where this pays off twice. A corporate card line for a hotel is one record; the folio behind it, with room rate, taxes, and incidentals broken out, is another. Those supporting documents can be pulled into the same structured shape, and extracting hotel folios for travel and entertainment spend lets you line the detail up against the card charge so T&E reconciles instead of sitting as a single opaque amount.

If you want spend analysis on top of allocation, an expense-category column is a useful addition. You can have each line classified by its description into categories such as travel, software and subscriptions, or office supplies, which our tool supports as a documented classification step at extraction time. Amounts arrive as native numbers in Excel rather than text, so they are ready for formulas and pivot tables the moment you open the file, with the summing still done by you in the sheet.

Handling Multi-Page Statements and Scaling the Workflow

A corporate statement is rarely one tidy page. Programs with many cardholders run long, with per-cardholder sections spread across a dozen pages or more, a cardholder's charges sometimes continuing past a page break. The propagation logic has to hold across those breaks: the header's name and last-4 keep applying to every line beneath them until the next header appears, even when that means carrying the attribution onto the next page. Done right, page count stops mattering and the attribution stays intact from the first cardholder to the last.

Long statements also carry pages you do not want: account-level summaries, balance recaps, rewards or marketing inserts, and total tables that would double-count spend if they reached the output. Instruct the extraction to skip them and pull only the detail transaction lines.

Adjustments need a deliberate hand. Credits, reversals, disputed-charge corrections, and fee adjustments belong in the data, but they are not ordinary purchases and should not be quietly folded in with them. Capture them as their own rows, with credits and reversals as negative amounts or marked by a document-type field, so that when you total a cardholder's spend the adjustments net correctly and the reconciliation ties out. Flagging them also makes a duplicate easy to spot, rather than burying it.

The point of building the workflow this way is that it repeats. The same prompt, or a saved version of it, applies whether you are processing one statement or a year of them across every cardholder in the program. That is what turns a one-time conversion into a monthly close routine: write the instruction once, reuse it each cycle, and get the same column structure every time. When you reach the point of deciding how to run the same extraction across many cardholders and months, our tool is built to extract corporate card statements into a structured spreadsheet at that scale: batches of up to 6,000 files and single PDFs up to 5,000 pages run through the same prompt, summary and cover pages are filtered out automatically, and the output is consistent across every document in the job. Every row also references the source file and page it came from, so any figure can be traced straight back to the line on the original statement when an auditor or a controller asks where it came from.