Self-storage arrears management: overdue is a workflow, not a red number.

A balance says money is outstanding. It does not say which invoice created it, what has already been allocated against it, whether an automated card attempt failed this morning, what the customer was told, which rental is live, or what the policy says should happen next. Working from the number alone produces inconsistent decisions and the same manual investigation every time.

Codemind Storage connects invoices, lines, allocations, payments, saved-card operations, disputes and rental context, then runs a staged past-due engine over the top. One operations queue computes the day of work: overdue accounts and lockout work beside failed payments, disputes, communications and tasks.

• Trace invoice, allocation and payment context rather than reading a detached total.
• See overdue work in the same daily queue as the exceptions around it.
• Run saved-card autopay with every payment operation recorded once.
• Raise stage fees, record collection notes and log a promise to pay.
• Send and track email, SMS or print from one template catalogue, with consent controls.
• Check a capability and audit the reason before a sensitive rental override.

A failed automated payment becomes visible work. Payment operations are recorded, so a retry or a re-delivered webhook converges on the attempt that already exists rather than becoming a second charge. The failure lands in the operations view with the customer, invoice and rental beside it.

The decline carries a category, because a card reported lost is not the same problem as a card with no funds this morning, and the two deserve different messages. Restarting automatic collection is an act by a person: a member of staff restarts it, or the tenant saves a new card in the portal. Nothing quietly re-arms itself against a card that has been failing for a fortnight.

As a staged progression that staff and automation share a vocabulary for. A facility can run stages such as Late, Locked Out, Pre-Lien, Lien and Auction, with a stage fee attached where the rule raises one. Ageing is computed from the invoice rather than stored as a status somebody can edit, so a stage is a consequence of the money rather than a label applied on top of it.

Lifecycle templates generate the communications, and an undelivered message stays as an operational exception rather than vanishing from the view. Collection notes and promises to pay sit on the account, with staff tasks beside them. It is a controlled past-due process, not a configurable visual workflow builder.

It should not, and here it does not. A transfer changes the unit and the rental relationship; it does not restart the customer account. The outstanding balance belongs to the customer ledger, and debt continuity is checked inside the transfer operation itself.

A customer in arrears or locked out may need an explicit policy decision before a transfer proceeds. Where an override is allowed, the capability is checked and the reason is audited, which is safer than hiding the exception in an unrestricted status edit or letting a new rental obscure what is still owed.

Ask how the system defines a balance, how partial payments are allocated, and what stops a duplicate request charging twice. Ask how a failure becomes staff work rather than a line in a gateway dashboard nobody opens. Ask whether a rental change can detach the debt, who may override an arrears control, and where the reason is stored.

On communications, ask whether the system proves delivery or only proves a template was created. On access, ask what happens when the door provider is offline, whether a restored account reverses an earlier suspension, and how staff see a failed instruction. Those answers are worth more than a feature cell marked collections: yes.

Collection runs on cards. There is no Direct Debit: a bank-debit provider connects, but no charging adapter exists behind that connection, and a scheduled attempt against a saved card is not a mandate. There is no card-account updater and no network tokens, so a card that expires or is reissued stops working until the customer saves a new one. There is no retry optimisation and no gateway failover either. One gateway, and a decline is handled as work rather than as a scheduling puzzle.

Lockout is modelled rather than integrated with a named provider. Lockout scope is real operational state and tenant door credentials can be revoked, but no provider-specific access adapter is claimed here, and nothing opens or closes a gate remotely. A genuine access integration has to carry suspension and restoration, delivery status, manual override and failure handling; asking any vendor for those four is the fastest way to test the claim.