P-Card Reconciliation: Process, Controls, and Exceptions

P-card reconciliation is the monthly process of verifying every statement charge against supporting evidence, its business purpose, and the correct accounting code. The cardholder or preparer assembles the record, an independent approver reviews it, and finance resolves or tracks outstanding exceptions before the audit package is archived.

“P-card,” “purchasing card,” and “procurement card” describe the same payment mechanism. Whatever term an organization uses, the control objective is the same: prove that the statement is complete, every transaction is authorized and business-related, the accounting treatment is supportable, and someone other than the cardholder has reviewed the result.

A sound P-card reconciliation process follows this order:

1. Establish the transaction population. Capture every posted charge, credit, fee, and dispute from the statement, then reconcile the row count and total back to the bank record.
2. Assemble sufficient evidence. Link each row to receipts, invoices, business-purpose notes, and dispute records as applicable.
3. Code and review the transaction. Record the GL account, department, project, grant, and tax treatment required by policy.
4. Classify exceptions. Put missing evidence, mismatches, restricted spend, duplicates, disputes, and coding questions into a named queue with an owner and due date.
5. Obtain independent approval. The approver reviews completeness, business purpose, coding, and exception resolution rather than merely signing a cover sheet.
6. Retain a traceable package. Archive the statement, row-level reconciliation, evidence, exception decisions, and approval record under the applicable retention policy.

The statement is the transaction population; receipts and explanatory documents are the supporting evidence. Starting with the receipts makes missing transactions difficult to detect. A usable monthly file therefore combines a source-document inventory, row-level reconciliation table, named exception queue, approval record, and archive index so a reviewer can trace any line from statement to evidence, coding, exception status, and approval.

Build a complete transaction population before matching receipts

Start with the bank-generated statement, not the documents cardholders happened to submit. Capture every posted purchase, credit, fee, and dispute, together with the cardholder or account identifier, transaction date, posting date, merchant, and amount. Then compare both the number of rows and the net total with the statement. If either control total differs, the population is not ready for reconciliation.

Each row also needs a source reference. At minimum, record the statement filename and page number so another person can locate the original entry without searching through the entire PDF. For a consolidated account, include the cardholder identifier as a separate field. Teams that first need to convert a multi-cardholder corporate card statement to Excel should preserve that statement structure rather than flattening away the account-level detail.

Build a source-document inventory alongside the transaction table. It should identify the statement files, receipts, invoices, credit memos, dispute records, and business-purpose notes received for the cycle. Phone photos, emailed PDFs, scans, and multi-page statements can all be valid inputs, but they still need stable filenames and a way to map them back to transaction rows.

Begin matching only after the population control totals pass. Give every row a match status, then compare candidate evidence using merchant, amount, cardholder, and transaction or posting date. Record the matched filename on the row. If one receipt supports several charges, several documents support one charge, or two candidates remain plausible, retain the relationship and flag it for review instead of forcing a one-to-one match.

A practical reconciliation table includes:

• statement account and cardholder
• transaction and posting dates
• merchant, amount, and transaction type
• statement filename and page
• receipt or invoice reference
• evidence and business-purpose status
• GL, department, project, grant, and tax fields
• exception class, owner, due date, and status
• preparer, approver, and approval date

Manual transcription is not itself a control. It consumes time while introducing its own omissions and keying errors. Invoice Data Extraction can extract P-card statement and receipt data into a structured spreadsheet from mixed batches of PDF, JPG, and PNG files. Users can define a consistent field schema, reuse a saved prompt, and download the result as XLSX, CSV, or JSON. Source-file and page references can be included in the output, while values needing human verification can be marked Review Needed.

That produces a structured preparation layer, not a completed reconciliation. The system does not establish that a receipt belongs to a particular charge, choose the correct GL or project code, decide whether a purchase complies with policy, resolve an exception, or provide independent approval. Those remain control decisions for the preparer, approver, and finance team.

---

Decide whether the supporting evidence is sufficient

“Receipt attached” is too weak a test. P-card receipt requirements should be framed around what the record proves: the merchant, date, amount, payment method, what was purchased, and why the purchase served the organization. No single document necessarily contains all six facts. An itemized receipt may identify the goods but omit the cardholder’s business purpose; a card slip may prove payment while showing nothing more than the total.

Review evidence as a set. The statement establishes that the charge posted to the account. A vendor receipt or invoice describes the purchase. A business-purpose note connects it to organizational work. For a hotel, conference, meal, or other policy-sensitive expense, the file may also need attendee, travel, agenda, or approval information under the organization’s rules.

The GAO purchase-card audit guide says evidence of cardholder reconciliation should include the monthly cardholder statement or another bank-generated transaction list, the vendor invoice or sales receipt, and documentation of formal disputes for unauthorized charges. That is a useful evidence baseline, not a universal file format or a replacement for the organization’s own documentation policy.

A payment confirmation is not automatically an itemized receipt. If it shows only the merchant and total, it cannot establish what was bought. Likewise, a receipt image with a cropped merchant name or unreadable amount is present but insufficient. Record the exact deficiency so the cardholder knows what must be supplied instead of returning the item with the vague status “receipt problem.”

When the original receipt is missing, request a duplicate from the merchant first. If it cannot be obtained, follow the organization’s P-card missing receipt affidavit or substitute-documentation process. The exception record should identify the transaction, explain why the original is unavailable, state the business purpose and items purchased, attach any corroborating evidence, and carry the required cardholder and approver acknowledgments.

An affidavit controls the exception; it does not make substitute evidence equivalent to the original receipt. Track repeated use by cardholder, merchant, and department. A single approved affidavit may close one row, while a recurring pattern can indicate weak cardholder practice, inadequate point-of-purchase capture, or a control that is being treated as optional.

Code each transaction as a reviewable accounting decision

Coding works best when it begins near the point of purchase, while the cardholder still knows what the charge was for. Deferring every decision to month-end forces AP to reconstruct context from merchant names, creates back-and-forth with cardholders, and increases the chance that a plausible but incorrect account is accepted simply to close the period.

The reconciliation row should carry the proposed GL account and any department, cost center, project, grant, or funding code required by the organization. Where the classification is not obvious, add a short note or supporting document that explains the decision. The preparer records the proposed treatment; the approver assesses whether it is reasonable for the documented purchase and business purpose.

Similar-looking charges can require different treatment. A restaurant transaction might relate to employee travel, client entertainment, or an employee-morale event, each subject to the organization’s accounting and tax policies. The reconciliation should capture enough context to make that distinction without pretending one coding rule or tax result applies everywhere.

Tax also needs an explicit review field. A card purchase on which the seller collected no sales tax is not necessarily tax-free. Depending on the jurisdiction and the buyer’s circumstances, finance may need to self-assess use tax on untaxed purchases. Flagging the row for qualified tax review is safer than asking cardholders or extraction software to make the determination.

Corrections should remain visible. If an approver changes a GL, project, grant, or tax treatment, preserve the original proposal, the corrected value, the reason, and the person who approved the change. That history turns coding into a reviewable accounting decision instead of an unexplained final value.

---

Run exceptions through named resolution paths

Purchasing card exception handling needs a queue, not a notes column labeled “discrepancy.” For each item, record the affected transaction row, exception class, description, owner, opened date, due date, status, required evidence, approver, and closed date. Useful statuses distinguish open, waiting on cardholder, under review, escalated, and resolved.

Define in advance what closes each class:

• Missing or non-itemized evidence: obtain the original or duplicate itemized document. If unavailable, complete the controlled substitute-documentation process and required approval.
• Duplicate charge: confirm that two statement rows represent the same purchase, then attach the merchant credit or dispute record. Do not close the item merely because a credit is expected.
• Unfamiliar merchant: obtain the cardholder’s explanation and evidence connecting the merchant’s billing name to the purchase. Escalate an unrecognized charge to the issuer’s dispute process.
• Amount, date, or merchant mismatch: document a defensible explanation, such as a tip, exchange-rate settlement, delayed posting, or trading name, and attach evidence supporting it.
• Apparent personal or restricted spend: obtain an independent policy decision and record reimbursement, disciplinary referral, or another required remedy. Cardholder intent alone does not settle compliance.
• Possible split transaction: review related charges together, including timing, merchant, requester, and aggregate amount, then record the independent determination and escalation.
• Credit or dispute: link the original charge, credit, and formal dispute documents. Keep the exception open until the financial effect and disposition are evidenced.
• Coding or tax-review flag: record the corrected code or tax determination, the rationale, and the authorized reviewer.

A resolved exception has evidence of both the decision and its required remedy. “Manager aware,” “old item,” or “will fix next month” does not close it. If policy permits a waiver, label it as a waiver, identify who authorized it, and preserve the rationale rather than reclassifying it as fully supported.

Questionable receipt evidence deserves its own escalation path. Cropped totals, inconsistent fonts, altered dates, duplicate images, or metadata concerns should prompt independent verification with the merchant, issuer, or original source. A reviewer assessing these cases can use methods to spot altered and fraudulent receipt evidence, but should not declare fraud from an image anomaly alone.

Separate preparation, approval, and program oversight

Segregation of duties matters more than a particular organization chart. The cardholder or preparer supplies the evidence, explains the business purpose, and proposes the coding. An independent approver challenges the completeness and reasonableness of that work. Finance or the P-card program owner monitors unresolved exceptions, policy compliance, and whether the cycle is ready to close.

A cardholder cannot independently approve their own reconciliation. In a small organization, the approver may be an owner, controller, or manager outside the transaction. In a larger program, approval may sit with a department supervisor or budget owner. The title varies; the control requires someone with enough authority and knowledge to question the purchase and no conflict created by having made it.

Approval should cover substance, not just arithmetic. The reviewer needs to confirm that:

• the statement population reconciles to the bank total
• evidence and business purpose are sufficient
• coding and funding appear reasonable
• restricted, personal, or split-purchase concerns were addressed
• credits and disputes remain tracked where unresolved
• each exception has an evidenced decision and remedy

Preserve the approver’s identity, approval date, scope of review, items returned to the preparer, exceptions accepted or escalated, and final disposition. An email, workflow record, or signed certification can provide approval evidence if it is retained with the package and clearly identifies what was reviewed.

Set a reconciliation deadline in policy, assign owners, and report approaching and overdue items. Do not borrow another institution’s number as a universal standard: reconciliation windows differ, as do escalation routes. Retention likewise follows the organization’s tax, funder, legal, and records obligations.

These roles sit within a broader accounts payable controls framework that also governs card issuance, spending limits, merchant restrictions, account access, evidence retention, and escalation. Finance oversight should test whether those controls work together, not treat the monthly sign-off as the entire P-card program.

---

Archive the reconciliation and monitor recurring control failures

P-card audit documentation should let a reviewer reconstruct the cycle without asking the original preparer what happened. Retain the statement or bank-generated transaction list, row-level reconciliation table, receipts and invoices, business-purpose support, coding and tax decisions, dispute documents, exception resolutions, cardholder certification where policy requires it, and independent approval evidence.

Add an archive index that maps each transaction row to its statement page and supporting files. Record the package version, close date, preparer, approver, and custodian. Stable filenames and page references matter: a link to an email inbox or an unlabeled folder of receipt images is not a durable audit trail.

Apply the retention period required by the relevant organizational, tax, funder, contractual, legal, and records policies. One institution’s schedule is not a safe default for another. If different documents in the package carry different requirements, document which rule governs the retained reconciliation copy and who authorized the schedule.

The completed cycle also supplies program-level control data. Monitor aged exceptions, repeated missing receipts, prohibited or unusual merchants, possible split purchases, duplicates, dormant cards, weekend or unusual-hour activity, and recurring coding or tax-review corrections. Look at frequency and concentration by cardholder, department, merchant, approver, and exception class rather than reviewing each event in isolation.

Use those patterns for targeted action. A cluster of non-itemized meal receipts may call for cardholder coaching or clearer evidence rules. Repeated split-purchase flags may warrant a limit and merchant-control review. Dormant cards should be validated or closed, while unresolved disputes and habitual late approvals need escalation to the program owner. Record the action taken so the next review can distinguish a recurring failure from a risk already under remediation.