Australian Fleet Card Statement to Excel: BP Plus, Caltex, Shell

To convert Australian fleet card statements to Excel, extract every BP Plus, Caltex StarCard/Ampol, Shell Card, Motorpass, FleetCard, and personal-card fuel receipt into one row-per-transaction spreadsheet. Use consistent columns for transaction date, invoice date, site, driver, vehicle ID, fuel type, litres, ex-GST amount, GST, total, rebate line, vendor-of-card, card source, source file, and FTC review status.

That single shape lets the bookkeeper reconcile the monthly statements, pivot fuel cost by vehicle or driver, and prepare BAS and Fuel Tax Credit workpapers without rebuilding each vendor export by hand. Invoice Data Extraction supports this workflow directly: upload the mixed statement PDFs, describe the unified columns in a reusable prompt, and download the fleet card data as Excel, CSV, or JSON.

Per-Vendor Statement Anatomy and What Each Portal Export Actually Gives You

Most Australian fleets end up with more than one fuel card because site coverage differs by route and region. That is why the extraction problem is not just downloading a portal export: BP Plus, StarCard/Ampol, Shell Card, Motorpass, FleetCard, and personal-card reimbursements still need to land in one consistent spreadsheet. Every AU fleet card produces a tax invoice for the statement period plus a transaction listing, and the vendor-specific export limits are where the workflow changes.

BP Plus. The monthly statement lists transactions with date, site, vehicle / driver / asset ID where the account has those fields configured, fuel grade and litres, ex-GST and GST amounts, total, and rebate lines from BP Plus Earn where eligible. The portal does offer a real Excel transaction download, which is the strongest portal export of any of the AU fleet cards. The catch is that the export is raw: the column headings aren't embedded in the file. The column-name reference lives separately in the BP Plus FAQ, so a bookkeeper opening the export for the first time has either to map columns by hand or set up a saved column mapping that survives between months. Once the mapping is in place, the export is reliable; before it's in place, the file looks like a wall of unlabelled numbers.

Caltex StarCard / Ampol. The statement lists transaction date, site (Ampol-branded or partner), card-holder reference, fuel grade, litres, GST-inclusive amount with GST shown separately, and AmpolCash rebate lines on eligible accounts. The self-service download from the StarCard portal is capped at a 35-day window per request and ships as a .txt file rather than Excel. The 35-day cap is the operating constraint that catches people out: a year-end review, an audit-period reconstruction, or any historical lookback past a single billing month means stitching together a series of downloads. For periods past the self-service window the practical input most bookkeepers actually have is the monthly statement PDF, which makes extraction the path rather than the export.

Shell Card. Administered through Viva Energy in Australia. The statement lists transaction date, site, card and vehicle reference, fuel grade, litres, ex-GST, GST, total, and any volume-rebate line where the account has one. Portal access varies by account type — larger accounts get a portal with structured downloads, but many smaller accounts receive a PDF statement by email each month and never see an Excel export. For those accounts the PDF is the primary input the bookkeeper has in hand, and extraction from the PDF is the only path to a structured shape.

Motorpass. The WEX-issued multi-network card. Its statement consolidates transactions across BP, Caltex/Ampol, Shell, 7-Eleven, Liberty, and other accepting sites within a single Motorpass invoice — useful, and marketed as ATO-compliant consolidated billing. The constraint is that the consolidation is within Motorpass. A fleet running Motorpass plus a separately-issued BP Plus card still has two statements to merge, and the Motorpass invoice itself doesn't carry the BP Plus Earn rebate line because the BP Plus rebate sits on the BP Plus account, not on the Motorpass invoice that paid for the fuel.

FleetCard. Also WEX-issued, with established accounting-software integrations — most visibly Xero, where transactions can flow structured into the ledger as they post. For accounts running the integration on current periods, the data is structured at source. The PDF statement is still the fallback for accounts without the integration, for periods predating activation, and for the year-end reconstruction cases where structured data is needed in spreadsheet form rather than already-posted ledger lines.

Across all five, the portal exports — where they exist — share three gaps that the unified spreadsheet has to close after the fact:

• No row-level FTC review fields. The exports record fuel type, but not the activity or use category that determines whether the row supports a claim.
• No card-source distinction for the forecourt-on-personal-card overlay. The vendor's own export, naturally enough, only knows about its own card. The apprentice's cash forecourt receipt is invisible to it.
• No unified shape across vendors. BP Plus's column order differs from Caltex's .txt structure, which differs from Motorpass's consolidated invoice. Per-vehicle pivots that work across the whole fleet need a single column shape, which means deciding on it once and either re-mapping every export or extracting straight to the unified shape.

That's where extraction earns its place. For multi-vendor consolidation, for out-of-window historical periods (Caltex's 35-day cap, Shell email-only accounts, end-of-year reconstructions), and for the PDF-by-email accounts that don't get a structured export at all, extracting directly from the statement PDFs into a unified column shape is faster and more reliable than chaining together vendor exports and re-mapping each one.

The Unified Per-Transaction Spreadsheet: Columns and the Vendor-of-Card Field

The shape that holds together across BP Plus, Caltex StarCard, Shell Card, Motorpass, and FleetCard is one row per transaction, with a fixed column set that every vendor's PDF maps into. Decide on the columns once, then run the same prompt against the next month's batch.

Recommended columns:

• Transaction date — the date the fuel was purchased, taken from the statement transaction line. Drives every analytical view downstream and the FTC consumption period.
• Statement period — the start and end dates of the parent statement. Useful for traceability back to the source PDF.
• Invoice date — the date the parent statement is invoiced. Supports BAS GST period selection (covered in the next section).
• Site / merchant — the branded forecourt or independent name as it appears on the line: BP Wagga, Ampol Tarcutta, Shell Coles Express South Yarra, an independent named on the receipt.
• Card holder / driver — the named driver where the account assigns transactions to a card holder.
• Vehicle / asset ID — the vehicle, asset, or unit number assigned to the transaction. Critical for per-vehicle pivots.
• Fuel type — diesel, petrol grade (91 / 95 / 98), AdBlue, LPG. Preserved separately because FTC review starts with it.
• Litres — the fuel volume on the line.
• Amount ex-GST — the pre-tax line amount.
• GST — the GST amount on the line.
• Amount total — the GST-inclusive line amount.
• Rebate / discount line — the AmpolCash, BP Plus Earn, or volume-rebate line as it appears on the parent statement, kept on its own row.
• Vendor-of-card — BP Plus, Caltex StarCard / Ampol, Shell Card, Motorpass, FleetCard, or "personal card – reimbursement" for the forecourt overlay rows. This is the column that makes the consolidation work.
• Card source — fleet card vs personal-card-reimbursement. A separate field from vendor-of-card so a Motorpass row and a personal-card row are both attributable cleanly: the Motorpass row shows vendor-of-card = Motorpass, card source = fleet card; the personal-card row shows vendor-of-card = personal card – reimbursement, card source = personal-card-reimbursement.

Two additional fields are worth keeping where the data exists: source file and page number (so each row points back to the exact PDF and page it was extracted from), and FTC review/status fields (covered in detail in the next section).

Rebate-line treatment is a deliberate choice the reader makes once and applies consistently. The two reasonable approaches:

1. Keep rebates as separate rows. Each AmpolCash, BP Plus Earn, or volume-rebate line becomes its own row with a negative amount, its own vendor-of-card, and the same site / driver / vehicle assignment as the parent transaction where the statement provides it. Audit-friendly, because the spreadsheet shape mirrors the source statement line for line.
2. Net rebates into the parent transaction. The rebate amount reduces the transaction's total in place, with no separate row. Cleaner per-vehicle KPIs, because the cents-per-litre figure already reflects the rebated price, but breaks the 1:1 correspondence with the source statement.

For any spreadsheet that feeds BAS or FTC work, the separate-row approach is the safer default. The rebate has its own GST treatment, the original statement carries it as its own line, and the audit trail benefits from matching that shape. The netted approach is reasonable for purely analytical reporting where audit traceability isn't the deliverable.

The forecourt-on-personal-card overlay merges into the same shape. The apprentice paid cash at a non-network site on Saturday morning; the owner used a personal card on a country run when no fleet-card site was on the route. Each receipt becomes one row in the unified spreadsheet:

• Transaction date, site, driver, vehicle ID, fuel type, litres, amount ex-GST, GST, and total taken from the receipt itself.
• Vendor-of-card set to "personal card – reimbursement", and card source set to "personal-card-reimbursement", so the row is attributable independently from the fleet card statements.
• The receipt scan stands as the substantiation for that row, in the same way the fleet card statement substantiates the fleet-card rows.

The result is a single spreadsheet with one row per fuel transaction across every card, every receipt, every vendor — the column shape is the same for a BP Plus pump fill on a Tuesday and a personal-card forecourt receipt on a Sunday. That uniformity is what unlocks per-vehicle pivots, BAS GST extraction, FTC review fields, and driver expense reporting from the same input.

GST and Fuel Tax Credit Flags at Row Level, Plus Transaction Date vs Invoice Date

Two regulatory layers sit on top of the unified spreadsheet: the BAS GST that comes off the GST column every quarter, and the Fuel Tax Credit working paper that starts from reviewed fuel-volume rows. Both are easier to defend if the eligibility decisions live at the row level rather than getting reconstructed from raw statements at quarter-end.

Row-level FTC review fields. Keep fuel type separate from use category. A practical spreadsheet uses one column for fuel type (diesel, petrol, LPG, AdBlue), one column for vehicle or equipment use, and one column for FTC status such as eligible, ineligible-light-vehicle-public-road, ineligible-private-use, excluded/non-fuel, or review. Diesel and petrol can both be taxable liquid fuels; the credit depends on how the fuel is used. AdBlue should stay in the spreadsheet for GST and reconciliation, but it should not be counted as eligible fuel litres for FTC.

The FTC status is reviewed per row, not reconstructed from raw statements at quarter-end. For the fleet-card-specific working paper, use the guide to turn fleet card statements into a Fuel Tax Credit spreadsheet. It covers rate-period splits, BAS 7D support, and per-vehicle allocation in more detail.

The ATO lists fuel card statements among the records that can support fuel acquisition details, and fuel tax credit records generally need to be kept for five years. Treat the unified spreadsheet, source PDF statements, and personal-card receipt scans as the acquisition evidence layer. For FTC claims, also keep the activity evidence behind the eligibility flag: vehicle or equipment use records, odometer or GPS data where relevant, job records, and worksheets showing how eligible and ineligible use was separated.

GST at the row level. Every Australian fleet card statement breaks GST out per transaction line, because the statement itself functions as the tax invoice and the line-level GST is what makes that work. Pull the GST amount through into its own column on the spreadsheet rather than recalculating it at the column-sum level — fleet card transactions occasionally include zero-GST lines (overseas supplier transactions on a multi-network card, certain rebate adjustments) and recalculating from a flat GST rate produces incorrect totals on those rows. Sum the column for the BAS figure; reconcile back to the parent statement's invoice total as a check.

The transaction-date vs invoice-date distinction matters more than it first looks. They feed different downstream tasks:

• For BAS, keep both the statement invoice date and the payment or direct-debit date. A non-cash GST reporter generally claims the GST credit in the period when the invoice is issued or payment is made, whichever is earlier; a cash-basis reporter generally claims it when payment is made. The spreadsheet should preserve the dates needed for the business's GST accounting basis rather than assuming every fleet card statement belongs in the invoice-date quarter.
• For FTC and for analytical reporting (per-vehicle costs, driver expense reports, route variance analysis), the transaction date is what matters because consumption happens transaction by transaction, regardless of when the parent statement was invoiced.

Keeping both columns means neither task needs reconstruction. BAS uses the date rules for the business's GST accounting basis; FTC and vehicle analytics use transaction-date periods. The spreadsheet feeds all three from the same row set without reshaping.

Rebate-line GST treatment follows the same row-level discipline. AmpolCash, BP Plus Earn, and volume-rebate lines have their own GST treatment as adjustments to the original supply, which is precisely why keeping them as separate rows (per the prior section's rebate recommendation) produces a cleaner BAS picture than netting them into the parent transaction. The rebate row carries its own GST column entry; the BAS-quarter sum picks it up correctly without the bookkeeper having to think about it.

Per-Vehicle and Per-Driver Pivots from the Consolidated Spreadsheet

The unified spreadsheet earns its place when the analytical view falls out of it without further data work. Three pivot shapes cover most Australian fleet needs:

Pivot	Row key	Useful measures
Per vehicle	Vehicle or asset ID	Total litres, ex-GST cost, GST, transaction count, average cents per litre, FTC-reviewed litres
Per driver	Driver	Total fuel cost, transactions per month, distinct sites, vendor-of-card mix, fleet-card vs personal-card reimbursement ratio
Per route or month	Route assignment or month	Total fuel cost, litres, vendor concentration, personal-card reimbursement share

Those pivots work because the upstream columns were preserved. Vendor-of-card enables vendor mix, card source enables fleet-card vs reimbursement analysis, and FTC status enables a claim-ready litres review.

Where the Spreadsheet Lands: BAS Posting, FTC Calculation, and the Monthly Workflow

The unified spreadsheet is the working artefact for the rest of the monthly cycle. For Xero users, it typically gets posted as a manual journal or reconciled against the fleet-card supplier bill that imports through bank feeds, depending on how the account is configured. The detailed BAS mechanics are the next workflow; readers taking the spreadsheet into that stage can prepare BAS in Xero for Australian businesses once the data is in shape.

Once the unified column set is defined and the extraction prompt is tuned to it, the month-two workflow is repeatable: drop in the new statements and receipt scans, run the same prompt, review the FTC status rows, and retain the spreadsheet plus source PDFs by statement period.