prev article
What I Learned After Trying to Model Strata Finance Properly
When I first started thinking about this problem, I assumed it was simple.
Strata finance is just about tracking payments, right?
Who paid, who didn’t, and how much is outstanding.
But the moment I tried to model it properly, that assumption broke down.
It’s Not a Payment Problem
At first glance, it feels like the main job is to record money:
- create charges
- record payments
- calculate balances
That part is straightforward.
The real complexity shows up when you try to answer questions like:
- Why is this unit still overdue?
- Did they already send payment?
- Did someone follow up?
- What happened last week?
That’s when you realize:
This is not just about money.
It’s about tracking what is happening over time.
Thinking in Terms of One Unit
To simplify things, I stopped thinking about the entire system.
I focused on just one unit.
Let’s say Unit A-12.
Every month, something predictable happens.
A new charge is created.
That charge represents what the unit owes for that month.
So far, nothing complicated.
Then Payments Come In
At some point, the resident makes a payment.
But here’s where things start to get messy in real life.
Payments don’t always match what is owed.
Someone might:
- pay partially
- pay for multiple months at once
- send the wrong amount
- send proof without clear reference
And most importantly:
The system cannot immediately assume the payment is valid.
So instead of marking it as “paid”, the system has to pause.
The payment exists, but it is waiting to be verified.
This small detail turns out to be very important.
Because this is where confusion usually starts.
One Payment, Multiple Charges
Another thing I didn’t expect at first:
A single payment is rarely clean.
If a unit owes for three months and pays one lump sum, that payment needs to be split across multiple charges.
So the system has to answer:
- which charge is being paid first?
- how much goes to each one?
- what is still left unpaid?
This is something spreadsheets struggle with.
Because it’s not just a list anymore.
It’s a relationship.
The System Is Actually a Timeline
The biggest shift in thinking came from this realization:
A unit is not just “paid” or “unpaid”.
It goes through states.
At different points in time, the same unit can be:
- newly billed
- overdue
- followed up
- promised to pay
- partially paid
- disputed
And these states don’t replace each other.
They build on top of each other.
Which means the system needs to remember:
- what happened
- when it happened
- who did it
Not just the final number.
Follow-Ups Matter More Than Numbers
Something else became very clear.
Most systems focus on:
- charges
- payments
But very few track what admins actually do.
In reality, collections depend heavily on:
- calling residents
- sending reminders
- negotiating payments
- escalating cases
If this is not recorded, the system is incomplete.
Because the most important question becomes unanswered:
What action has been taken so far?
Not Everyone Pays the Same Way
Another layer of complexity is human.
Some residents:
- always pay on time
- occasionally delay
- never pay unless chased
- request installment plans
Treating all units the same doesn’t work.
So the system needs a way to categorize behavior.
Not to label people—but to prioritize attention.
Because not all overdue cases are equal.
From Tracking to Clarity
At this point, I realized I wasn’t just building a way to record data.
I was trying to build something that answers a simple but powerful question:
Who needs attention right now?
That’s very different from:
Who hasn’t paid?
Because the first leads to action.
The second just creates a list.
What This Changed for Me
This shifted how I think about the system entirely.
Instead of focusing on features, I’m now focusing on:
- how information flows
- how states change over time
- how decisions are made
The system is less about storing data, and more about making the current situation clear.
Where This Is Going
Now that the workflow is clearer, the next step is to translate this into something structured.
A system that can:
- track charges and payments properly
- handle partial and multi-month payments
- record follow-ups consistently
- classify units automatically
- surface what needs attention
That’s what I’ll be building next.
If You’re Dealing With This
If you’ve ever had to manage collections, follow up on overdue payments, or piece together financial records manually, you’ve probably seen some version of this.
I’m actively building in this space, and also open to working with teams that want to improve their internal systems.
You can reach me here:
https://axelyn.com/