American Express C31 is an evidence problem about representation. The Cardmember says the goods or services received were different from the written description provided when the transaction occurred. The merchant should therefore build a file that can answer two questions without ambiguity: what was promised, and what was actually delivered?
Current product pages are a poor substitute for historical offer data. Save the version tied to the purchase date.
Identify the precise written promise
Extract the concrete statements that matter: model, quantity, condition, dimensions, included features, service hours, deliverables, support period, compatibility, or access term. For a service contract, use the signed scope and accepted change orders. For digital plans, use the plan matrix that applied at signup.
Avoid building the case around slogans. “Professional grade” and “best in class” do not help a reviewer compare the transaction. Specific commitments do.
Turn the complaint into a measurable comparison
Find the Cardmember’s actual complaint. If they say the product was a different model, compare model numbers. If they say a feature was absent, show whether the purchased plan included it. If they say the service was incomplete, list completed and missing deliverables.
This approach can reveal that the merchant is wrong. If the written offer did promise something that was not delivered, that should trigger remediation rather than creative wording in the dispute response.
For C31, retain the written description that existed when the customer paid. Product specifications, service scope, compatibility statements, dimensions, condition grading, expected performance, and delivery format can all become relevant depending on the complaint. Then document the delivered item or service with serial numbers, photos, completion records, or customer acknowledgements. The goal is a side-by-side comparison, not a pile of evidence that only proves a transaction occurred.
Show delivery quality and scope
Packing slips, serial numbers, inspection records, work logs, deliverables, and account entitlements can demonstrate what the customer received. Pair each record with the written promise it supports. A long appendix is less useful than a clear link between commitment and performance.
For partial service disputes, separate the delivered portion from the undelivered portion and check whether the dispute amount corresponds to the full transaction or only part of it.
Include the resolution path after complaint
If the merchant offered replacement, repair, troubleshooting, return, or partial refund, preserve the communication and outcome. A customer who refused a reasonable remedy can be relevant, but state that neutrally. If the merchant failed to respond, do not omit the gap.
The reviewer should be able to see whether the issue remained unresolved when the Cardmember went to the issuer.
Use C31 data to improve the offer itself
Repeated “not as described” disputes can signal weak merchandising even when support thinks the products are fine. Review which phrases, features, or images show up in complaints. For services, check whether sales promises exceed delivery scope.
Archive every material product-page change and plan-feature change. That history improves future dispute evidence and also helps the business understand whether customer expectations were created by its own copy.
Pay particular attention to marketing claims. If the customer relied on a statement that was ambiguous, exaggerated, or absent from the merchant's formal specifications, the dispute may expose a merchandising issue rather than a payments issue. Feed recurring C31 complaints back to product and marketing teams, and version important customer-facing pages so the business can reconstruct the actual representation made at the transaction date.
Example: Amex C31 where the service scope changed in writing
A customer books a package with three deliverables, then agrees by email to replace one deliverable with another. Later the customer disputes the service as not described based on the original proposal. The merchant should preserve the original scope and the written modification, then show what was actually delivered under the revised agreement.
If the change was only discussed verbally and not recorded, the case is weaker. This illustrates why change orders and scope modifications should become part of the transaction record before work continues.
Turn a description dispute into an auditable specification comparison
For C31, freeze the promise as it existed when the customer bought. Physical products may require model, variant, size, material, color, condition, bundle contents, or compatibility. Services may require scope, deliverables, timing, performance criteria, or documented exclusions. If the offer changed after purchase, preserve the earlier version. A current webpage cannot prove what the customer saw months earlier, especially when the business has since corrected a confusing listing.
Next, translate the customer's complaint into discrete assertions. If the customer says a service was incomplete, identify which deliverable is alleged missing. If a product was defective, identify the defect rather than answering only with shipping proof. Build a table with promised attribute, delivered evidence, customer allegation, and merchant response. This format exposes gaps quickly: a merchant may have excellent delivery evidence but no record showing that the delivered variant matched the one ordered.
Include change history. Many service disputes arise after scope changed by email, support chat, or a change order. Preserve both the original agreement and the later modification, including customer acceptance. For merchandise, substitutions, backorders, or replacement items can also change the transaction story. If the merchant knowingly substituted something different, explain the customer's consent or the remedy rather than pretending the original description remained exact.
Finally, reconcile remedies and amount. A repair, replacement, re-performance, partial refund, return authorization, or discount can narrow what remains at issue. State what was offered, accepted, and completed. If the merchant fixed only part of the problem, defend only the value still supported by the record. Use C31 data to find recurring expectation problems—one SKU, supplier, sales script, landing page, or service team may generate disproportionate 'not as described' complaints even when payment processing is functioning perfectly.
Use a remediation matrix when the customer complains about several description defects
A single C31 complaint can contain several issues—wrong feature, delayed delivery, missing accessory, and poor support. Create one row per complaint with promised state, delivered state, remedy offered, remedy completed, and remaining value. This prevents one successful fix from being presented as though it resolved every allegation. It also helps the merchant narrow a defensible amount when part of the service or product was corrected and another part genuinely failed.
Check whether the customer complaint targets the original scope or a later revision
Service and product descriptions can evolve after the sale, and the disputed complaint may refer to a later version rather than the original promise. Preserve dated proposals, change orders, revised specifications, and the customer's acceptance of each material change. Then identify which version the customer says was breached. If the merchant delivered the revised scope correctly, show the written modification. If the customer never accepted the change, do not use an internal project note as though it replaced the original agreement. This version-control step prevents the C31 file from comparing the complaint with the wrong promise and also helps the business identify whether scope changes are being documented consistently enough to survive later review.
VERIFY CURRENT RULES
Primary references
Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.