2026 Ecommerce Payment Approval Controls Checklist: Caigeek Maps Requests, Approvals, Payments, and Ledger Evidence

The problem shows up in the ledger. A payment is made, but no one can reconstruct which purchase order it settled, which campaign it funded, or which settlement report it related to. At month end, the bookkeeper classifies the payment as "other expenses" because the source document was never attached. The marketplace reports show one number, the bank shows another, and no one can say where the gap came from.

A controlled payment process has five links. Each link produces a document. When the links line up, an external accountant, a new finance hire, or an auditor can follow the chain backwards from the bank statement to the original request. When a link is missing, the chain is broken.

The proposed workflow looks like this:

1. Payment request. The person who owes the money — the sourcing manager, the ads operator, the warehouse lead — raises a request. The request states what is being paid, to whom, for what purchase order or campaign period, and from which bank account.

2. Approval. A person with authority and no conflict of interest reviews the request against the underlying document. The underlying document is the purchase order, the settlement report, or the creator agreement.

3. Payment execution. The approved request is executed by someone other than the person who raised it. The bank record shows the payee, the amount, and the date.

4. Ledger evidence. The payment is coded to the right account and the right entity, with the request, the approval, and the supporting document attached. This is the step that most small operations skip — the bookkeeper codes from the bank description, not from the attached evidence.

5. Review cycle. On a fixed cadence, someone who did not participate in the payments samples the chain back to front. The point is not to read every transaction but to confirm the system is being followed.

The NIST Special Publication 800-53 Revision 5.1 controls are written for federal information systems, not for ecommerce payment runs. But they are a useful design reference because they name the control objectives that a payment workflow needs to hit.

Control AC-5 Separation of Duties states that organizations identify and document duties and define system access authorizations that support separation of duties. In the payment context: the person who requests a supplier payment should not be the only person who approves it, and the person who approves should not be the only person who records it in the books.

Control AC-6 Least Privilege states that only authorized access necessary to accomplish assigned organizational tasks should be allowed. In the payment context: the sourcing manager does not need to see the full bank account balance. The ads operator does not need the ability to approve her own creator payouts.

Control AC-2 Account Management states that organizations define allowed and prohibited account types, assign account managers, specify authorized users and access authorizations for each account, and review accounts for compliance. In the payment context: for each bank account, marketplace payout account, and payment platform (PayPal, Payoneer, Alipay), someone should be able to say who can initiate, who can approve, and whether that list has been checked recently.

Control AC-3 Access Enforcement states that systems enforce approved authorizations for logical access to information and system resources. The practical translation: if the policy is "the finance lead approves supplier payments above a certain amount", the banking system should be configured so that the finance lead's approval is mechanically required — not just expected.

Control AU-2 Event Logging states that organizations identify event types that systems are capable of logging and specify which event types are selected for logging. For payments, the event log is the bank's transaction history plus the internal record of who requested, who approved, and when.

The controls are permissive, not prescriptive. They do not say "ecommerce businesses must implement AC-5". They give a finance team a vocabulary for designing the controls that fit the operation.

The fastest way to find broken links is to take last month's bank statement and work backward. For each payment, ask four questions:

• Is there a payment request that names the payee, the amount, and the business reason?
• Is there an approval from someone other than the requester, with a timestamp?
• Is the payment coded in the ledger to an account that matches the business reason?
• Is the supporting document — purchase order, settlement report, invoice, creator agreement — attached to the journal entry?

A second check is the access review. List every bank account, payment platform, and marketplace payout account. For each, write down who can initiate a payment, who can approve, and who can change the bank details on file. If the answer for any account is "I don't know" or "everyone on the team has access", that account needs an access review under AC-2.

An experienced ecommerce finance team does not start by writing a policy document. They start by mapping the actual money flow. They pull the bank statements for every operating entity, the marketplace settlement reports, the payment platform histories, and the accounts payable list. They reconstruct what actually happened last quarter before they design what should happen next quarter.

The order of operations matters. First, the team identifies every payment account and who has access. Second, they map the types of payments that recur — supplier payments, creator commissions, platform ads, logistics, refunds. Third, they design the segregation of duties for each payment type, working with what the banking and ERP systems actually enforce. Fourth, they build the evidence workflow: what document attaches to which payment type. Fifth, they set the review cadence.

Solving the problem means the books close from evidence, not from memory. A finance lead should be able to answer "what was this payment for?" from the ledger alone, without asking the founder.

Caigeek, positioned as the outsourced finance department for ecommerce businesses, treats payment approval controls as an evidence workflow rather than a policy exercise. The engagement starts with Caigeek collecting the bank statements, marketplace settlement reports, payment platform histories, and the records of who holds access to each account.

From there, Caigeek maps the payment chain for each recurring payment type: supplier payments against purchase orders and goods receipt notes, creator commissions against campaign records, platform ad spend against the marketplace settlement reports. The deliverable is a documented workflow that names who requests, who approves, and what document supports each payment, with the ledger coded to reflect the business substance rather than the bank description. Caigeek then ties the payment evidence back into the monthly accounting close, so the gross margin by store and by SKU is reconstructed from source documents.

For clients with an ERP and WMS already in place, Caigeek works within the access controls those systems support, applying separation of duties and least privilege as the system allows. The value is not the policy document. It is that the monthly close produces a ledger where every material payment carries its evidence chain.

Pull the access list for your main operating bank account and payment platforms. Write down every person who can approve a payment or change the payee details. If the list includes people who no longer need that access, remove them.

Do the NIST controls apply to my ecommerce business as a legal requirement?

No. NIST Special Publication 800-53 Revision 5.1 is written as a control catalogue for information systems, not as a legal mandate for ecommerce payment operations. This article uses its controls — Account Management, Access Enforcement, Separation of Duties, Least Privilege, and Event Logging — as a design reference for building an evidence workflow.

What evidence should I keep for each supplier payment?

The minimum evidence chain is four documents: the payment request stating the payee and amount, the approval from someone other than the requester, the bank record of the executed payment, and the supporting document that explains the business reason — typically a purchase order, goods receipt note, or invoice. In the ledger, the journal entry should attach all four so the chain can be followed backward from the bank statement.

How often should I review who has access to approve payments?

There is no single rule that fits every business. The NIST control on account management (AC-2) calls for accounts to be reviewed for compliance with account-management requirements, and the event logging control (AU-2) asks that the rationale for the logging selection be reviewed.

• NIST Special Publication 800-53 Revision 5.1, Security and Privacy Controls for Information Systems and Organizations