Audit trails for payments and billing: what to log and what to review

An audit trail for payments is a permanent, time-stamped record of who did what in your billing and payment systems: who created an invoice, changed a customer's details, issued a refund, exported a report or added an API key. When everything is going well, nobody looks at it. When money goes missing, a customer disputes a charge, or an auditor asks how a figure was produced, it is the first thing everyone wants.

This guide covers what a useful audit trail records, which events deserve regular review, and how to use one without drowning in log entries.

Why payments and billing need an audit trail

• Fraud prevention and detection. Internal fraud often involves small, quiet changes: a bank account edited, a refund to an unusual account, a discount that shouldn't exist. An audit trail makes those changes visible and attributable.
• Disputes. When a customer says "I never agreed to that plan change", a record of who changed it, when and from where settles the question.
• Segregation of duties. Controls like "the person who creates a refund shouldn't approve it" only work if you can see who did each step. See role-based access control for finance teams.
• Audits and month-end. Accountants and auditors want to see how numbers were produced and who changed them.
• POPIA accountability. If personal information is accessed or changed inappropriately, you need to know whose account did it and what was affected. Our POPIA payment data guide covers your wider obligations.

What a good audit log records

Each entry should answer five questions:

For changes to important records, the before and after values are valuable too, as long as sensitive data such as full card or bank numbers isn't copied into the log.

Events worth logging

Not every click needs an entry, but these do:

Access and security

• Sign-ins, failed sign-ins and password resets.
• Two-factor authentication turned on or off, backup codes used, failed codes.
• Users invited, removed or given a different role.
• Roles and permissions created or changed.
• API keys created or revoked.

Money movement

• Refunds recorded or issued.
• Payments recorded manually, such as cash or EFT, and payments approved from proofs of payment.
• Changes to payment gateway settings and bank details.
• Debit order mandates approved and batches submitted.

Customer and billing data

• Customer details changed, especially email addresses and billing contacts.
• Invoices created, edited, cancelled or credited.
• Subscriptions created, changed, paused or cancelled, and by whom (staff or the customer).
• Discounts and coupons applied.

Data leaving the system

• Reports and customer lists exported.
• Bulk downloads of documents.

What to review, and how often

An audit log nobody reads is only half a control. A light routine works for most businesses:

Weekly (15 minutes):

• Refunds: who issued them, to whom, for how much, and why.
• Changes to bank details, gateway settings, roles and API keys.
• Manual payments and approved proofs of payment.
• Data exports.

Monthly:

• Users and their roles. Remove anyone who has left or changed jobs.
• Failed sign-ins and two-factor failures, looking for patterns.
• API keys still in use, and whether each one is still needed. See API key security.

On any incident:

• Pull every action by the affected user or key for the relevant period, and preserve it.

Ideally the reviewer is someone other than the people whose actions are being reviewed. In a small business that may be the owner or an external bookkeeper.

Making audit logs trustworthy

• No editing. Users, including administrators, shouldn't be able to change or delete entries.
• Restricted access. Viewing the audit log should itself be a permission, held by few people.
• Retention. Keep entries long enough to cover your dispute windows, financial year-end and audit cycle.
• Consistent time. Use one time zone, clearly stated.
• No secrets in logs. Never log passwords, full card numbers or API keys. Log a key's public prefix, not the key.

Common mistakes

• Shared logins. If three people use one account, the audit trail can't tell you which of them acted. Give everyone their own user.
• Everyone is an admin. Broad permissions make the log longer and the controls weaker.
• Logging everything, reviewing nothing. Choose the high-risk events and look at those.
• Forgetting integrations. Actions taken by API keys and connected systems belong in the same trail as human actions.

How CentraPoint helps

On plans that include it, CentraPoint keeps an audit log under Settings that records the actions of your dashboard users and API keys together, with the source (dashboard, API or customer portal), the outcome and the IP address. Successful API write calls are recorded with the key that made them, and every API request is kept in a separate request log for 90 days, without request bodies or secrets.

Sign-in attempts, failed two-factor checks and password resets are recorded, along with two-factor changes, role changes, refunds, report exports and customer portal sign-ins. Viewing the audit log is a permission that only admins hold by default, and custom roles let you decide who else can see it. Gateway notifications have their own webhook log showing whether each was verified. See roles and permissions and two-factor authentication in the docs.

Frequently asked questions

What is the difference between an audit trail and a transaction history?

A transaction history shows payments and their statuses. An audit trail shows the actions people and systems took, including changes that aren't payments, such as edited customer details, new users or exported reports.

How long should we keep audit logs?

Long enough to cover your dispute windows, financial year-end and any audit or legal requirements that apply to you. Your accountant or auditor can advise on the right period for your records.

Who should be able to see the audit log?

Only a few people: usually owners, finance managers and whoever reviews controls. Viewing the log should be a separate permission from day-to-day billing work.

Should API activity appear in the audit log?

Yes. Integrations can create invoices, record refunds and change customers just like people can, so their actions should be attributed to the specific key that made them.