Recurring payments are administratively dull and easy to get wrong.
Somebody has to remember who paid this month, reset everyone to unpaid when the new month starts, and keep a running total that survives the reset.
Done by hand in a spreadsheet, it takes an afternoon a month and produces arguments.
This walkthrough shows a Lark Base that does it with one formula pair and one automation, built around a co-living operator collecting monthly rent.
The Scenario
Utopia Heaven Sdn Bhd runs co-living accommodation and was tracking tenant records and fees manually. The base below replaces that with a single Tenant details table where the payment cycle resets itself each month and every payment is banked into an all-time total.
The same pattern fits any recurring charge: membership fees, equipment rental, retainer billing, subscription costs.
How the Table Is Built
One table holds everything, organised into three field groups.
Basic information
Tenant ID, name, age, contact details, nationality, occupation, employer or college, and how they found the company. Room number, move-in date and the rental start date sit here too.
Note: If you build something similar, keep identity documents and demographic fields out of any view that gets shared or screenshotted. Under PDPA you should only be holding what you actually need, and a room allocation table rarely needs an identity card number on display.
Contract
The tenancy dates, contract length, renewal history and deposit confirmations.
- Start date (T) and End date (T): The tenancy period.
- Period: How long the tenant has been resident, in years and months.
- Contract Type (months): Six or twelve.
- Created, Start and End date (C): The current contract’s own dates.
- Renewal Confirmation: A button field to trigger a renewal.
- Prev. Contract Renewal and Contract renewal times: Renewal history.
Payment
This group does the work.
- Deposit Fee, Rental Deposit and their confirmation checkboxes.
- Rental monthly (RM): The monthly charge, set by room type. In this base a master room is RM1,000 and a medium room RM650.
- Rental paid: A single-option field holding Paid or Unpaid.
- nextRental_date_before: The date the next payment is due by.
- Owe by tenant (RM): Outstanding this month.
- Paid (RM): Paid this month.
- Total paid (RM): The all-time running total.
Tip: The three money fields are what make this work. Keeping this month separate from all time means the monthly figure can be cleared on a cycle without destroying the payment history.
Recording a Payment
At any point some tenants have paid and some have not.
The two unpaid tenants show RM650 and RM1,000 under Owe by tenant (RM), matching their room types. When payment arrives, staff switch Rental paid from Unpaid to Paid and three things follow:
- nextRental_date_before rolls forward a month, so 07/12/2025 becomes 07/01/2026.
- Owe by tenant (RM) drops to zero.
- The amount lands in Paid (RM) for the month.
Automating the Monthly Reset
Manually switching everyone back to Unpaid at the start of each month is exactly the chore worth removing. A single automation handles it.
The trigger
Choose At record’s trigger time, select the Tenant details table and the nextRental_date_before field, then set when it should fire relative to that date.
The actions
One Update record step pointed at the record from step one, setting three fields:
Rental paid becomes Unpaid, opening the new month’s cycle.
Total paid (RM) absorbs this month’s payment:
SUM([Record in step 1].[Total paid (RM)], [Record in step 1].[Paid (RM)])
Paid (RM) resets to zero:
SUM([Record in step 1].[Paid (RM)], -[Record in step 1].[Paid (RM)])
Important: Both formulas read from Record in step 1, meaning the values as they were when the automation fired. That is what allows one step to bank the payment and clear the field without the second action wiping out the first.
What Happens When It Fires
Every tenant is back to Unpaid, Paid (RM) is empty, Total paid (RM) has grown by the amount that was there, and Owe by tenant (RM) is charged at the monthly rate again. Tracing one row: a tenant showing RM2,600 paid and RM0 total before the run shows RM0 paid and RM2,600 total afterwards, with RM650 back on the balance.
Note on timing: Firing several days before the due date gives tenants warning, but it also flips them to Unpaid while the month they have already paid for is still running. Firing on the due date itself keeps the status honest at the cost of that early warning. Decide which matters more to your team before going live, and test with one record first.
Adding Payment Reminders
The automation can carry a second action.
Add a message step after the update and the same trigger that resets the cycle also notifies staff, or the tenant directly, that rent is due.
That turns a bookkeeping routine into a collections process without anyone maintaining a reminder list.
Practical Use Cases for SMEs and Startups
- Co-living and property rental: Rent, deposits and arrears per tenant, with contract renewal dates in the same record.
- Gyms and membership businesses: Monthly fees that reset on each member’s own renewal date rather than a shared billing day.
- Equipment hire: Recurring charges per item, with a running total per customer.
- Agency retainers: Monthly billing status by client, plus lifetime revenue in the same table.
- Subscription tracking: Company software and service costs, reset monthly with an annual spend total accumulating alongside.
Frequently Asked Questions (FAQ)
Can Lark Base track recurring monthly payments automatically?
Yes. A date field holding the next due date can trigger an automation that resets the payment status, banks the month’s payment into a running total and reapplies the charge.
How do I keep a payment history if the monthly figure gets cleared?
Use two number fields. One holds the current month and is cleared on each cycle; the other accumulates every payment before the clear happens, giving you an all-time total that survives the reset.
What triggers the monthly reset?
The At record’s trigger time trigger, pointed at a date field on the record. Each tenant resets on their own due date rather than everyone resetting on the same calendar day.
Why subtract a field from itself instead of just entering zero?
It achieves the same result while keeping the action consistent with the other formula-driven field in the same step. Setting the value to zero directly works equally well if you prefer it.
Can different tenants have different monthly amounts?
Yes. The monthly charge is a field on the record, so it can vary by room type, plan or contract. The automation reapplies whatever that record’s own rate is.
Can the automation also send a payment reminder?
Yes. Add a message action after the update step and the same trigger that resets the cycle will notify staff or the tenant that payment is due.
Should the automation run before or on the due date?
Both work. Running early gives advance warning but marks tenants Unpaid before the paid month has finished; running on the day keeps the status accurate. Test with a single record before applying it to everyone.
Letting the Base Do the Bookkeeping
Nothing here is complicated in isolation.
A date field, a status field, three number fields and one automation.
What makes it worth building is that the monthly ritual disappears entirely: the cycle resets itself, the history accumulates, and staff only ever touch a record when money actually arrives.
Ready to Power Your Business with Lark?
Lark Base is just one part of an all-in-one platform that brings messaging, meetings, documents, approvals, and automations together for your entire team.
As the Platinum Partner for Lark in Malaysia, Exabytes offers tailored Lark plans, hands-on onboarding, and dedicated local support to help your team automate the routines that eat their month.
