Payments Demystified v32: Exceptions and Adjustments
Last operator focused post of the series, let's talk about exceptions, what happens when the money flow breaks
Now that we have covered ledger design and reconciliation, the next logical step is what happens when the money flow breaks, because in card programs, not every transaction resolves cleanly.
Authorizations fall off
Settlements arrive late
Duplicates happen
Adjustments need to be posted
Operational teams have to make corrections without making the financial system less trustworthy
This is where exceptions and adjustments come in. Honestly, this is one of the most important operating muscles in a mature card program, and one of the clearest differences between a system that works in theory and a program that can survive real life.
In practice, card programs are not defined just by how well they process happy-path transactions, they are also defined by how well they recover when things go wrong.
In this post, I want to break down what exceptions actually are, why they happen so often, how adjustments fit in, and why operational recovery needs to be handled with just as much care as the original transaction flow.
What an exception actually is
At a high level: an exception is any situation where a transaction or balance does not move through the normal flow in the expected way.
This can mean a transaction did not complete cleanly
It can mean two systems disagree
It can mean money moved differently than expected
Or it can mean the ledger needs intervention to reflect reality correctly.
Exceptions are not rare edge cases, they are a normal part of operating a card program.
The question is not whether they will happen, the question is whether your systems and teams are prepared to detect them, investigate them, and resolve them without making things worse.
Why exceptions happen so often
The payments stack has a lot of moving parts.
You have: customer actions, merchant behavior, network rules, processor logic, sponsor bank funding, ledgering, reconciliation workflows, support processes, and finance dependencies all connected together.
That means exceptions can happen for a lot of reasons:
a merchant sends an unexpected settlement
an authorization never clears
a reversal arrives late
a duplicate message gets processed
a refund behaves differently than expected
a file arrives incomplete
a matching key is weak or missing
a downstream system retries something incorrectly
manual operations create a correction with incomplete context
Sometimes the issue is technical.
Sometimes it is operational.
Sometimes it comes from a partner.
Sometimes it is just the natural messiness of the real world.
That is why exception handling is not a niche function.
It is part of the everyday reality of issuing.
Common exception types in card programs
Not every program sees the same patterns, but a lot of exceptions tend to show up repeatedly. Here are a few examples.
Authorizations that never settle
A card was authorized, a hold was placed, but the transaction never reached final settlement.
Sometimes that is normal.
Sometimes it is a release logic problem.
Sometimes the customer ends up seeing money tied up longer than they should.
Settlement that does not match the original auth
The transaction clears for a different amount than originally authorized.
That can happen in restaurants, fuel, travel, hospitality, and a number of other merchant categories.
If the system is not designed for this well, balances and customer transaction history can get messy quickly.
Duplicate presentments or duplicate postings
A merchant or downstream system submits the transaction more than once, or the internal system posts it more than once.
Now the question becomes whether the duplicate is real, whether it should be blocked, and how to correct it cleanly if it already hit the ledger.
Reversals that arrive late or incompletely
A transaction is reversed, but the timing or message sequence does not line up neatly with the original hold or posting flow.
That can leave available balance, posted balance, and transaction history out of sync.
Refund timing issues, and even unlinked refunds
Refunds are often assumed to be simple, but they can create their own complexity.
A refund may arrive long after the original transaction.
It may not map cleanly.
It may create confusion for the customer if the original transaction and refund are not represented clearly, and in many cases refunds aren’t linked cleanly back to the original transaction.
Network, processor, or file-related mismatches
Sometimes the issue is not a single transaction at all.
A file may be delayed.
A batch may be incomplete.
A processor record may not align to internal ledger state.
Funding may not tie to expected activity.
These are often some of the most stressful exceptions because they can affect larger groups of transactions at once.
Manual correction scenarios
Something went wrong, and the only practical next step is a manual intervention.
That may be necessary, but it is also where a lot of long-term risk gets introduced if the controls are weak.
What an adjustment actually is
An adjustment is a controlled ledger action used to correct, offset, or reflect financial reality when the normal transaction flow did not produce the right result.
That is important.
An adjustment is not supposed to be a shortcut for avoiding root-cause work.
It is supposed to be a deliberate correction mechanism.
Good adjustments are:
clearly reasoned
traceable
tied to a specific problem
approved appropriately
visible in audit and reporting flows
Bad adjustments are the opposite, they are vague, hard to trace, loosely governed, and used too often as a way to “just make the number work.”
That is where trust in the ledger starts to erode.
The danger of fixing the symptom but not the truth
One of the easiest traps in payments operations is solving the immediate issue without actually restoring financial truth.
For example, maybe a customer balance looks wrong, so someone posts a quick correction.
The customer experience is improved in the moment, which is good, but if the underlying mismatch was not understood, documented, and connected back to the source issue, then the program may now have a cleaner-looking surface and a weaker financial history underneath it.
That is the danger.
Adjustments can make the ledger look cleaner while making the system harder to trust over time, this is why mature teams treat corrections seriously.
The goal is not just to fix what is visible, the goal is to restore correctness in a way that remains explainable later.
Why manual fixes can become dangerous
Manual intervention is sometimes unavoidable.
There are situations where a team really does need to step in and correct something directly.
But manual fixes are risky for a few reasons.
First, they do not scale well.
Second, they often depend on tribal knowledge rather than durable process.
Third, if they are not governed carefully, they create inconsistent treatment across similar cases.
And fourth, once a team gets too comfortable solving recurring issues manually, it can hide the need for deeper system improvements, and in some cases, even cause unwanted customer behavior that spirals out of control.
In other words, manual corrections are sometimes necessary, but they should never become the operating model.
If a certain class of exception keeps requiring human intervention, that is usually a signal that the workflow, matching logic, controls, or ledger design needs to improve.
What strong exception handling looks like
A mature card program does not assume that exceptions can be eliminated, it assumes they will happen and builds the operating model accordingly.
That usually means a few things.
Early detection
Issues should be surfaced quickly through reconciliation, monitoring, alerts, and operational review processes. The longer an exception sits undetected, the more expensive it usually becomes to untangle.
Clear classification
Not every exception is the same. Teams need a way to distinguish between customer-impacting issues, accounting-impacting issues, partner-related issues, duplicate risks, release failures, and broader systemic mismatches.
That helps route the issue correctly and prioritize response.
Strong investigation paths
A good team can trace from the visible problem back to the underlying cause. That means being able to connect transaction events, ledger entries, processor records, and settlement or funding evidence without having to rebuild the story from scratch every time.
Controlled resolution paths
If an adjustment is needed, it should happen through a controlled workflow with proper reason codes, approval standards, and auditability. You do not want important financial corrections happening through informal side channels.
Feedback into system improvement
This is the part weaker teams miss.
The point is not just to resolve each exception one by one. It is also to identify recurring patterns and use them to improve the product, the controls, and the underlying infrastructure.
The best operators do not just close tickets.
They reduce future breakage.
Why this matters so much in mature programs
As a program grows, exception volume usually grows too.
Not just because transaction count increases, but because complexity does.
You add more use cases.
More partners.
More transaction patterns.
More edge cases.
More operational surfaces.
More reasons for two systems to disagree.
That is why mature programs invest heavily in this area.
Not because they expect perfection, but because they understand that operational recovery is part of scale.
A program that cannot handle exceptions well will eventually slow down under its own weight.
A program that can detect, classify, investigate, and correct issues cleanly builds real resilience.
If you’re learning something new from this series
Payments Demystified is a reader-supported publication.
To get new posts and support my work, consider becoming a free or paid subscriber.
Disclaimer: The views and opinions expressed in this publication are solely my own and do not represent the views, positions, or policies of any current or former employer or any organization with which I am or have been affiliated. The information provided is for educational purposes only and should not be construed as legal, financial, or professional advice.
What’s next
Now that we have gone deep on some of the core mechanics that make card programs work, I want to zoom back out a bit.
Because once you understand the infrastructure, the next interesting question is what people have built on top of it.
So next, I am kicking off a new series on innovations in fintech: how they got here, what they actually do, and how they work under the hood.
The goal is to walk through some of the most important fintech innovations, not just from a product perspective, but from an infrastructure and operating-model perspective too.
A lot of the most interesting products in fintech are really new ways of packaging, abstracting, or rethinking the same core financial rails.
