22 August 2026 · 8 min read
How to manage user balances from the admin dashboard
Adjusting a balance is the control new operators are most nervous about and end up using most often. It is a normal operation. Doing it carelessly is what causes problems, not doing it at all.
When do you actually need to adjust a balance?
Five situations come up repeatedly. None of them are unusual.
A deposit that never credited: The payment arrived on chain but the callback failed, or the user sent from an exchange that stripped the reference. The funds are real and the user is right. You credit manually.
A deposit sent to the wrong address: The user paid to an old address, or to a different coin's address. Sometimes recoverable, sometimes not. Either way the decision is yours and it ends in a manual adjustment.
A wrong amount credited: Rounding on a gateway, a partial payment, a fee deducted that your software did not expect. The balance is wrong by a small amount and needs correcting in either direction.
A goodwill credit: Something went wrong that was your fault. Downtime, a delayed payout, a bug. A small credit costs less than the support conversation.
A correction after a dispute: You investigated, the user was right, you put it back.
Notice what is not on that list: changing a balance because the platform is short. That is not an admin operation, it is the beginning of a problem you cannot fix in the panel, and it is worth being honest with yourself about the difference.
How do you do it safely?
Four rules, and they take about thirty seconds longer than doing it carelessly.
- Find the evidence first: The transaction hash, the gateway reference, the support message. Never adjust from memory.
- Write the reason in the reason field, not in a note somewhere else. Six months later that field is the only thing that will remind you.
- Adjust once, for the exact amount: Two adjustments to reach the right number look like something went wrong even when nothing did.
- Tell the user what you did and why, in the same session. An unexplained balance change generates a support message even when it is in their favour.
If your software has separate credit and debit actions rather than "set balance to", prefer them. A credit of 40 is a record of what happened. Setting a balance to 240 hides both the previous value and the size of the change.
An admin controlled investment platform, installed and configured for you. Full admin control, live in 6 to 12 hours, from $149.
What does the log have to record?
An adjustment that is not logged did not happen, as far as any later argument is concerned. The entry needs six things:
| Field | Why it matters later |
|---|---|
| Admin account | Which person, not just "admin" |
| Timestamp | Ordering against the user's own transaction history |
| Amount and direction | Credit or debit, exact figure |
| Balance before and after | Proves nothing else changed in between |
| Reason | The only context you will have in six months |
| Reference | Transaction hash or ticket number |
The log must not be editable by admins, including you. That is the entire point of having one. There is more on this in inside the admin panel.
Four mistakes that cost real money
Adjusting before checking the chain: A user says a deposit did not arrive. It did not arrive because they never sent it, or sent it to a different platform. Check the transaction before you credit anything. This is the single most common way operators get worked.
Crediting the gross rather than the net: If a gateway takes a fee, the amount the user sent and the amount you received are different numbers. Credit what arrived, and explain the difference rather than absorbing it silently.
Fixing a balance without fixing the cause: If a callback failed once it will fail again. Correcting the symptom five times is slower than finding out why.
Adjusting during a dispute rather than after it: Once you move the balance, you have effectively decided. Investigate first, decide, then act, and say so in that order.
Handling a dispute you cannot immediately resolve
Sometimes the evidence is genuinely unclear. The pattern that works:
Freeze the withdrawal, not the account, unless you suspect fraud. Freezing an account looks like an accusation. Holding one withdrawal while you check looks like process, and process is what people accept.
Tell the user what you are checking and roughly how long it will take. Then meet that time, even if the answer is "still checking". Silence is what turns a disagreement into a public complaint on a forum.
Whatever you decide, write it in the reason field. If the same user disputes something again in three months, past-you will have left present-you the context. The same discipline applies to profile edits, where two fields need more care than the rest: editing user profiles and KYC records.
What changes when more than one person can adjust balances?
The moment you have support staff, split the permissions. Most support questions do not require changing a balance, and the ones that do are worth a second pair of eyes.
A pattern that works for small teams: support can read everything and credit up to a small fixed amount for goodwill. Anything larger needs you. That removes the bottleneck for the routine cases and keeps a limit on the damage any one account can do.
One login per person, always. Shared admin accounts make the audit log worthless, because every entry says the same thing.
The workflow described here is what the balance screen in our admin panel is built around, documented on the admin panel page. The adjacent workflow, approving payouts, is covered in how the withdrawal queue really works.
Common questions
When is it legitimate to adjust a balance?
A deposit that arrived with the wrong reference, a gateway callback that failed, a correction after a dispute, or a goodwill credit you have decided to give. All routine, all worth recording.
What has to be logged with every adjustment?
The admin account, the amount, the balance before and after, a timestamp and a reason. An entry without the before value and the reason is close to useless six weeks later.
What is the most common mistake?
Making the change first and writing the reason later, or not at all. The context is clear in the moment and gone by the time somebody disputes it.
Should support staff be able to adjust balances?
No. Support is the role most likely to be persuaded under pressure. Route adjustments to a second person who can look at the history with nobody waiting on them.
What if a user says their deposit never credited?
Check the transaction record and the gateway before touching the balance. If the funds genuinely arrived, correct it and write what you verified in the reason field.
Can adjustments be reversed?
Make a second, opposite adjustment with its own reason rather than trying to erase the first. The pair of entries is the record of what happened.
How do I handle a user who keeps asking for credits?
Consistently, and in writing. A short standing rule you apply the same way every time is easier to defend than a series of individual decisions.
Question this did not answer? Ask on Telegram. Reader questions get written up first.