AmEx Business Platinum & Gold Statement to Excel

AmEx Business Platinum and Business Gold are charge cards, not revolving credit cards: the full balance is due each cycle and there is no carried liability. Each statement consolidates every supplemental cardmember under one central bill account, with a separate transaction section per person and a per-cardmember subtotal. Foreign currency charges break out into four fields on each row — the foreign currency amount, the AmEx exchange rate, the USD amount that posts to the central bill, and a foreign transaction fee. The right general-ledger pattern is a clearing account that nets to zero each cycle when payment lands, not the revolving-credit-card payable used for personal credit cards.

Convert an AmEx Business Platinum statement to Excel for any reason other than a quick glance and those four facts shape the work. AmEx ships native exports for recent periods; older periods or the full multi-cardmember statement structure run through the PDF, and the rest of this page works through that distinction in detail.

Two notes before the rest of the page. If you have a personal AmEx — Gold, Platinum Personal, Blue Cash, Cash Magnet, any of the consumer cards — the document and the bookkeeping shape are different, and the generic AmEx personal statement to Excel walkthrough is the right page for you.

If you have AmEx @Work or Corporate Cards rather than Business Platinum or Business Gold, that is a different product line entirely. The download path runs through the @Work portal, the export already carries fields you would otherwise have to add yourself (employee names, cost centers, accounting codes), and the receiving software stack is typically Concur, Coupa, or an ERP-side T&E module rather than QuickBooks Online or Xero. This article addresses the small-business charge-card audience — Business Platinum and Business Gold — and is not the right reference for an @Work or Corporate Card program.

The rest reads as a bookkeeping workflow, organized around those four Business-card-specific complications.

Charge card versus revolving credit: the GL model that changes everything

Most of the bookkeeping difference between a Business Platinum statement and a personal Visa statement comes down to a single regulatory distinction. The Regulation Z definition of a charge card treats it as a credit card on an account for which no periodic rate is used to compute a finance charge. There is no carried balance because there is no mechanism to charge interest on a carried balance — the full amount is due each cycle and that is the deal. Business Platinum and Business Gold sit inside that definition. Personal credit cards do not.

That regulatory shape drives the GL model. Because there is no revolving liability, the natural posting account is a clearing account: a charge-card-type liability or asset-clearing account, depending on how the chart of accounts is laid out, that exists to receive the cycle's transactions and clear them when the payment lands. Statement transactions post into that clearing account through the cycle. The payment to AmEx posts the offsetting entry. The account nets to zero by the end of the cycle.

A revolving credit card payable looks different in motion. Charges go in, the company pays some portion at month-end, the unpaid remainder carries forward, finance charges accrue on the carry, and the running balance is the working liability the books track against the issuer's statement balance. None of that applies to a charge card. There is nothing to carry forward, nothing to accrue against, and the GL question at any point in the cycle is not "what is my balance" but "what has posted into the cycle so far."

The reconciliation consequence follows directly. For a charge card, the reconciliation question is whether the cycle's transactions plus the payment net to zero — not whether a running liability balance ties to the issuer's statement balance. A clean cycle close is a clearing account at zero after the payment posts. If it is not at zero, something either failed to post on the transaction side or the payment did not match the closing balance, and the diagnostic runs against those two specific surfaces rather than against an open carried balance.

The same logic generalizes to other charge cards a small business might hold; Business Platinum and Business Gold are the canonical examples on this page because that is the audience.

The clearing-account model still works when the central bill account consolidates several supplemental cardmembers — the normal case here — but the per-cardmember sections want their own posting blocks under the parent, which the next section walks through.

The central bill account and per-cardmember statement structure

Open the PDF and the structure is consistent across cycles. The first pages carry the central bill account header — previous balance, payments and credits, new charges, fees, total amount due — followed by a separate section for each supplemental cardmember showing that person's transactions and their per-cardmember subtotal, and finally a summary block with payment instructions and any account-level fees. Each cardmember has their own login at americanexpress.com and sees only their own activity there, but billing rolls up to the central bill account and the statement is a single document.

The spreadsheet shape that supports a real bookkeeping workflow follows from that structure. One row per transaction. A Cardmember column populated from the section header that the row appeared under. Standard columns for transaction date, posting date, description, and amount. Foreign currency fields where present (covered in detail in the next section). The per-cardmember subtotal lines drop out of the transaction rows and exist only as reconciliation references. The central bill account totals — closing balance, fees, credits, payment due — reconcile against the sum of cardmember subtotals plus any account-level fees and credits, and that arithmetic is the cycle's tie-back.

The QuickBooks Community and Fourlane threads on AmEx multi-cardmember reconciliation surface the same friction repeatedly: bookkeepers know they need a parent and sub-account structure but cannot find a clean walkthrough of how to set it up against a Business Platinum statement. The pattern that works is straightforward. The central bill account becomes a parent account of charge-card type. Each supplemental cardmember becomes a sub-account beneath it. Transactions post to the sub-account corresponding to whichever cardmember section they came from in the statement. The parent account balance equals the sum of the sub-account balances at any point. The payment to AmEx posts at the parent level when it clears, and the parent and rolled-up sub-accounts net to zero as the cycle closes.

Class is the typical QBO dimension for project, client, or cost-center allocation, and it sits on the transaction line in addition to the cardmember sub-account, not instead of it. A line for a partner's flight to a client engagement posts to the partner's cardmember sub-account and carries a class for the client project; both pieces of information are needed and both have somewhere to live. The categorization step that takes a cleaned spreadsheet and lands each row in the right account and class combinations is its own piece of the close — the reference on how to categorize statement transactions for GL posting covers that workflow as a general pattern, applied here to the AmEx multi-cardmember structure.

Xero supports the same pattern with different vocabulary. The central bill account is a charge-card account; supplemental cardmembers can be set up as sub-accounts beneath it where the chart of accounts allows it, and tracking categories play the role of class for project or client allocation on the transaction line. Some Xero teams with simpler reporting needs run a single charge-card account and embed the cardholder name in the line description; that works for two- or three-cardholder accounts but stops scaling cleanly past that.

Sage Intacct collapses the structure into its native dimension model. The parent charge-card liability account sits at the chart-of-accounts level; cardmember is one dimension and project, department, or cost center is another, applied to the transaction line. Multi-entity firms layer entity dimensions on top of those, and the dimension hierarchy handles per-cardmember reconciliation, project allocation, and entity reporting in a single posting structure rather than three.

Whichever system, the reconciliation tie-back is the same. The per-cardmember subtotals from the spreadsheet sum to the central bill account closing balance after fees and credits are applied. The cycle reconciliation is the spreadsheet against the statement closing balance, not against an issuer-side carried liability.

Foreign currency charges and the four-field FX line

A foreign-currency charge on a Business Platinum or Business Gold statement carries four separate pieces of data, and getting all four into the spreadsheet is what gives the books a defensible audit trail.

The fields are the foreign currency amount in the original currency, the AmEx exchange rate applied to that amount, the USD amount that posts to the central bill, and the foreign transaction fee AmEx adds on top — published in the cardmember agreement at 2.7% on Business Platinum at writing, which the current agreement should be checked against because AmEx has revised the rate before. The description field carries the merchant name and usually the merchant city and country, which is useful for analytics but is separate from the FX fields proper.

The spreadsheet shape is one row per transaction with the FX fields broken out into their own columns alongside the standard ones: foreign amount, foreign currency code, exchange rate, USD amount, and foreign transaction fee. All on the same row as the underlying merchant transaction. The audit value of capturing all four is concrete: anyone reviewing the books later, including an auditor or a successor bookkeeper, can reconstruct the FX math from the original document without going back to the PDF and re-deriving it. Capture the fields once at extraction and the audit trail stays clean for the life of the books.

The posting choices follow from what each field actually is. The USD amount posts to the expense line because that is what cleared the cardmember's account and that is what the GL has to record. The original-currency amount is captured as a memo or reference field on the line, not posted to the GL — it exists for audit, not as a posting figure. The foreign transaction fee is the field where firm policy varies. Most controllers post it to a dedicated bank charges or foreign exchange fees account rather than burying it in the underlying expense category, because that keeps the underlying expense clean and surfaces total FX cost as a discrete line in management reports. Other firms post it inline with the related expense to keep the cost-of-the-trip or cost-of-the-vendor view whole. Either treatment is defensible and the article is not going to legislate; pick one consistent with firm policy and apply it the same way every cycle.

For accrual-basis firms with material FX exposure, one further point. The AmEx-applied exchange rate is the rate that actually moved cash and it is the rate that should govern the books for the transaction itself, regardless of any internal hedge rate or treasury monthly rate. Multi-currency QuickBooks Online, multi-currency Xero, and the Sage Intacct FX module all let the per-transaction rate post to the expense and reconcile any internal-rate variance to its own variance account separately. That separation keeps the underlying expense recorded at what it actually cost and isolates the policy-level FX accounting where it belongs.

Membership Rewards Business in the description field

AmEx layers Membership Rewards Business categorization into the description field of many transactions on a Business Platinum or Business Gold statement. These are the bonus-earning category tags that drive points multipliers — transit, US shipping, US advertising in select media, technology purchases through Business Gold, and the rest of the categories the cardholder enrolled in or that AmEx applies automatically. They are real signal for spend analytics, year-end Membership Rewards reporting, or any internal dashboard that tracks bonus-category attainment. They are not GL data.

The practical decision splits on the destination of the spreadsheet. Keep the categorization when the spreadsheet itself is the analytics destination — spend by category for a partner-meeting recap, bonus-category tracking against the year's spend plan, or any working file the bookkeeper or controller is using to think about the spend rather than to post it. Strip it when the spreadsheet is being imported into QuickBooks Online, Xero, or Sage Intacct. The categorization clutters the description field, complicates transaction matching when bank feeds independently surface AmEx descriptions on the cleared payment, and confuses Bank Rules in Xero or QBO that try to match cleaned descriptions to expense accounts.

In extraction practice, that means the description column for accounting imports should carry only the merchant-identifying portion of the description, and the Membership Rewards categorization should land in a separate optional column that can travel or not depending on the destination. The same source extraction can serve both audiences with the analytics column included or excluded; the underlying transaction is the same either way.

One note on Business Gold specifically. The flexible bonus-category selection — where the cardholder picks the categories that earn 4x points at enrollment and can change them periodically — means the categorization that appears on the description is account-specific rather than a fixed taxonomy across all Business Gold accounts. Treat it as account-level metadata for the cardmember rather than as a stable categorical attribute of a merchant or a transaction type.

---

Native AmEx exports and when you have to pull from the PDF

AmEx ships several native download options for Business Platinum and Business Gold cardholders, and the choice between them — and between any of them and a PDF extraction — comes down to the period covered, the structure preserved, and what the destination accounting system actually wants.

The Activity page on americanexpress.com offers CSV, Excel, and OFX/QBO downloads covering roughly the past 6 billing statements. The Statements & Activity area offers PDF, Excel, and CSV statement downloads for roughly the past 2 years. Older periods generally require a request to AmEx customer service for the historical statement. These figures are sourced from AmEx's own published customer-service documentation and the writer should re-confirm them at the time of any specific workflow decision because AmEx has revised retention windows in the past and may again.

The Activity-page CSV is a transaction dump — transaction date, posting date, description, amount, and a category. It is suitable for a quick reconciliation glance, or for the simplest single-cardholder accounts where the bookkeeper is happy to add cardmember and any FX detail by hand, or for a sanity check against another data source. It is not suitable for the per-cardmember posting block model from the prior structural section because it does not preserve the per-cardmember section grouping; everything is flattened into one stream. It is not suitable for the FX field treatment either, because the foreign-currency amount, exchange rate, and foreign transaction fee do not break out into separate columns; the row carries the USD amount and the rest is implicit in the description text. Recognize what the Activity-page CSV is — a useful tool, not a substitute for a structured extraction — and use it where it fits.

PDF extraction becomes the right path when the period falls outside the native download window, when the full statement structure (per-cardmember sections, FX field breakout, fees, opening and closing balances) needs to land in the spreadsheet, and when the bookkeeper wants to keep a single consistent extraction pattern across every month rather than switching between Activity-CSV and statement-PDF based on age. That last reason is the practical one for any recurring monthly close: a stable workflow that produces the same spreadsheet shape every cycle is worth more than the convenience of a one-click CSV that drops half the structure.

At a practitioner level the mechanics are straightforward. A structured extraction reads the PDF, identifies the cardmember section headers, maps each transaction to the cardmember section it appeared under, breaks FX line items into their constituent fields, and outputs a spreadsheet shaped the way the multi-cardmember section above described — one row per transaction, a Cardmember column, FX fields broken out, subtotals available for the reconciliation tie-back. The reader can do this manually for a single statement (open the PDF, type the transactions into a spreadsheet, work the FX math by hand) and that approach is fine for a one-off historical request. For any recurring workload this article assumes a tool of some kind.

That is where AI-powered statement and invoice data extraction earns its place in this workflow. The product reads the PDF, identifies the per-cardmember sections, maps each transaction back to its cardmember, and breaks FX line items into the four fields above, in a single pass. Users describe what they want in a natural-language prompt — for the kind of statement this article covers, a goal-oriented prompt works well: something along the lines of "I'm reconciling an AmEx Business Platinum statement; extract one row per transaction with columns for Cardmember (taken from the per-cardmember section header), Transaction Date, Posting Date, Description, USD Amount, Foreign Currency Code, Foreign Currency Amount, Exchange Rate, and Foreign Transaction Fee where present; skip per-cardmember subtotal rows; output as Excel." The same prompt produces the same spreadsheet shape across every month's statement, and the underlying batch processing handles older historical PDFs the same way it handles current ones.

For completeness on the native exports: the AmEx-side OFX/QBO download covers roughly the same window as the Activity-page CSV, and for cycles inside that window it is a clean import path into QuickBooks Online if OFX is what the team prefers. For older periods or for the full-structure cases above, the workflow is PDF extraction first, then a PDF to OFX, QFX, and QIF conversion for accounting imports when the destination accounting software prefers a financial-exchange import over a spreadsheet import. Most QBO, Xero, and Sage Intacct workflows accept Excel or CSV directly, so the OFX step is only worth taking when the destination genuinely benefits from it.

Readers whose mix of statements extends beyond AmEx Business cards — a Chase business operating account, a Capital One Spark Business card, a brokerage statement — will find the general bank and card statement to Excel reference covers the broader pattern; the four-complication structure here is specific to Business Platinum and Business Gold, but the underlying extract-then-post discipline carries.

Posting the statement in QuickBooks Online, Xero, and Sage Intacct

With a clean extracted spreadsheet — one row per transaction, Cardmember column populated from the per-cardmember section header, FX fields broken out where present, descriptions cleaned of Membership Rewards categorization — the posting workflow runs the same way each cycle in each of the three systems most small-business teams are using.

The shape is the clearing-account workflow set up earlier. Statement transactions post into the parent charge-card account through the cycle, the payment to AmEx posts the offsetting entry at the parent level when it lands, and the parent (with its rolled-up sub-account or dimension structure) nets to zero. That cycle close — clearing account at zero after the payment posts — is the reconciliation question for a charge card. The revolving-credit-card workflow of running balances and finance charges does not apply.

In QuickBooks Online, the spreadsheet imports through Bank Transactions on the parent charge-card account, with each row coded to the appropriate sub-account by cardmember and to the appropriate expense account by category, plus class for project, client, or cost-center allocation. Firms that prefer the rigor of a period-end journal entry over the matched-feed workflow can post the spreadsheet as a JE against the same accounts and dimensions instead — same coding, different posting mechanism. Either way, the structural pattern from earlier — central bill account as parent, supplemental cardmembers as sub-accounts, class on the line — drives where each row lands. For the cycles that fall inside AmEx's native OFX window, the AmEx-side OFX/QBO download is an alternative for that period; for everything outside it, the spreadsheet path from this article is the workflow. Multi-currency QBO accepts the foreign-currency amount and exchange rate fields if they are imported as such, and the USD amount on the expense line is what posts to the GL regardless.

In Xero, the parent charge-card account at the chart-of-accounts level holds the central bill account. Where the chart of accounts allows it, supplemental cardmembers go in as sub-accounts beneath the parent; teams with simpler reporting needs run a single charge-card account and embed the cardholder name in the line description, which works for two- or three-cardholder accounts and starts to break down past that. Tracking categories handle project or client allocation on the transaction line — the Xero counterpart to QBO class. The cleaned description field matters operationally here because Xero's Bank Rules try to match descriptions to expense accounts on import, and a description still carrying Membership Rewards Business markers will not match cleanly against rules built around merchant identity. Multi-currency Xero accepts the foreign-currency amount and exchange rate fields and posts the USD equivalent to the expense line.

In Sage Intacct, the dimension model carries more of the structure than separate accounts do. The parent charge-card liability account sits in the chart of accounts; cardmember is one dimension on the transaction, project or department is another, and entity is layered on top for multi-entity firms. The per-cardmember reconciliation, the project allocation, and the entity reporting all happen through the dimension hierarchy on a single posting structure rather than three nested account hierarchies. The FX module handles foreign-currency transactions through the standard multi-currency posting flow, and the AmEx-applied exchange rate from the statement is the rate that should govern the transaction line — the principle of letting the rate that actually moved cash drive the expense applies here directly.

The rhythm of the cycle close looks the same in all three systems. Post the cycle's transactions. Post the payment when it clears. Confirm the parent charge-card account nets to zero. Sign off the cycle. The reconciliation question is whether the cycle closed flat, not whether a running balance ties to anything.

One last operational note. AmEx's Business Platinum statement posts on a calendar cycle defined by the account, not by the firm's accounting close. Some teams adopt the AmEx cycle as the close cycle for the charge-card account to keep the clearing-account workflow simple, with the rest of the books closing on the calendar month and the AmEx clearing account closing on its own statement date. Others post on calendar months and let the cycle straddle close periods, accruing for the in-cycle transactions that sit on the wrong side of the calendar break. Either approach is workable; the choice tends to follow whether the firm's reporting cadence is loose enough to absorb a charge-card cycle that does not align with the calendar, or tight enough that the alignment is worth engineering. Make the choice once and apply it consistently.