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.

If you are converting an AmEx Business Platinum statement to Excel for bookkeeping rather than a quick review, those four facts shape the spreadsheet. 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.

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 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.

For a clean accounting setup, treat the central bill account as the parent charge-card account and each supplemental cardmember as a sub-account or dimension 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, and the payment to AmEx posts at the parent level when it clears.

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. Larger programs that need to split a corporate card statement by employee into a spreadsheet and allocate each line to its department or GL code are better served by sub-accounts or dimensions from the outset.

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. 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; choose the one that matches firm policy and apply it consistently each 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.

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.

AmEx's help center says recent activity and the past six billing statements can be downloaded to Quicken, QuickBooks, or CSV, while the previous two years of transactions can be viewed and downloaded as PDF, Excel, or CSV. For older archived statements, use the statement list or contact AmEx support if the period is not available online.

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.

For accounting imports, keep the merchant-identifying description clean and move Membership Rewards category text to an optional analytics column. Those tags may help spend analysis, but they are not GL data and can confuse QBO or Xero matching rules.

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.

For recurring PDF work, AI-powered statement and invoice data extraction can read the statement, preserve the per-cardmember sections, map each transaction to the right cardmember, and split FX rows into the required fields. A reusable prompt can ask for one row per transaction with Cardmember, dates, description, USD amount, foreign currency code, foreign amount, exchange rate, and fee; skip subtotal rows; output Excel. The same prompt keeps monthly statements and older PDFs in the same shape.

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 follows the clearing-account model above. Transactions post through the cycle, the payment to AmEx posts at the parent level when it lands, and the parent account should net to zero after the cycle closes.

In QuickBooks Online, import the spreadsheet through Bank Transactions on the parent charge-card account, with cardmember sub-account, expense account, and class on each row. A period-end journal entry can use the same coding if the team prefers JE control over matched-feed posting. Multi-currency QBO can carry the foreign-currency amount and exchange rate fields while the USD amount posts to the GL.

In Xero, use the parent charge-card account for the central bill account. Supplemental cardmembers can be sub-accounts where the chart allows it, or cardholder names can live in the line description for smaller accounts. Tracking categories handle project or client allocation, and the cleaned merchant description matters because Xero Bank Rules match on description text.

In Sage Intacct, keep the parent charge-card liability account in the chart and put cardmember, project, department, and entity detail into dimensions. The FX module should use the AmEx-applied exchange rate from the statement because that is the rate that moved cash.

One last operational note: choose once whether the AmEx statement cycle or the calendar month controls close timing. Some teams close the charge-card account on AmEx's cycle date; others accrue in-cycle transactions across month-end. Either approach works if it is applied consistently.