List your ledger entries

Every movement on your balance, newest first, keyset-paginated. This is the reconciliation surface: close a period by walking it rather than by adding up webhook events, so an event you missed, or one you had resent, changes nothing about what you can rebuild.

amount_cents is signed, credits positive and debits negative, which is what lets a page sum to the movement in your balance across it. Read the direction off that sign and never off type.

type says where a movement came from. The pair worth knowing is the one a wasted trip produces:

• provider_charge is the delivery fee billed for a late cancellation or a return trip, one fee per leg that was driven, less your own store markup. Negative, and tied to the order that caused it. This amount changed on 2026-08-29: it used to be what the wasted trip cost Listo, so expect larger values on the same orders from that date onward. The row itself is unchanged.
• provider_charge_reversal is that charge credited back in full, when the cost turns out not to have been owed. Positive, and posted as its own row against the same delivery_id rather than as a reduction of the original charge, so what you were billed and what came back are both still readable. It can arrive weeks after the charge. Pair the two by delivery_id and expect equal and opposite amounts.

A third value can appear on the same order and is a different amount under a different heading:

• order_value_reimbursement is the value of an order a courier collected that reached nobody, credited after we claim it. Positive, tied to the order it belongs to, and NOT paired with any debit on this ledger: the order’s value never moved through your balance, so there is nothing to net it against. It is decided case by case and is not guaranteed, so never derive it from the order total or expect one per incident.
• listo_charge_correction is a charge Listo made in error and gave back: a provider_charge that turned out not to be yours to pay. Positive, tied to the order it corrects, and posted as its own row beside the original charge, never as a reduction of it. Pair it with the charge by delivery_id; it can be less than the charge, and an order can carry more than one. It is decided case by case, so never derive it from a charge or expect one per charge.
• requote_adjustment is the difference between the fee your order was charged and the fee the courier network booked for its trip, when the two are not the same. Signed: negative when the booked trip cost more than you were charged, positive when it cost less. Tied to the order, posted as its own row beside the order’s own charge and never as a rewrite of it, and a retry of the same order trues it up to the trip finally booked rather than adding another. It is not paired with any other row, and it is uncommon.

One more is money you earn, and it is a credit:

• developer_share is what you earn on a delivered trip of your own store, credited to you when the trip is delivered. Positive, and tied to the order it belongs to. A trip that is canceled or returned earns none.

Two more are a store’s Plan Listo, paid from your balance:

• plan_charge is one month of a store’s plan, IVA included. Negative. A month paid by card writes no row, because it never touched the balance.
• plan_extra_charge is the WhatsApp assistant’s conversations past what a full store’s plan includes, charged to you with that store’s plan. Negative.

store_id names the store a movement belongs to, on every row: the store of the order, or the store whose plan was paid. It is null when a movement belongs to no single store, such as a top-up or a withdrawal.

This vocabulary GROWS. New values can appear in any release, because v1 changes additively and a movement you cannot yet name is still money that moved. So branch on the values you know and let the rest fall through: count an unfamiliar type toward the balance, show it, and do not drop it or reject it. Rows you discard are the difference between your books and GET /v1/balance.