Rent settlement is an operations problem

Rent does not stop moving. A tenant pays, an agency deducts its commission, taxes get withheld, and an owner is paid the remainder. The transaction is simple. The operation around it, run by hand every month, is where the cost hides.

In Colombia, 40% of households rent — the highest rate in Latin America. Small agencies manage a meaningful share of that stock, and most of them run collection and settlement the same way: a bank transfer in, a spreadsheet calculation, a bank transfer out, reconciled after the fact.

Collection and settlement are one problem, not two

Payment processors are good at moving money. They are not good at knowing that a given transfer is rent, that it belongs to a specific unit, or that 3.5% of it needs to be withheld before an owner sees a peso.

Vertical CRMs built for real estate are good at managing listings, leases, and tenant communication. They are not built to calculate a tax withholding correctly or generate the report format a tax authority expects.

Each tool solves half the operation. The agency staff close the gap manually, and the manual step is exactly where errors, delays, and disputes come from.

Withholding has to be exact, not approximate

Tax withholding is not a rounding exercise. A withholding rate applies to a specific base, under specific conditions, and has to be reported in a specific format. Getting it approximately right produces a discrepancy that surfaces months later, at reconciliation or audit time, when it is much more expensive to fix.

A withholding calculation should be a small, testable function with an explicit contract — not a formula buried in a spreadsheet cell that nobody remembers building:

type Settlement = {
  grossRentCents: number;
  commissionRateBps: number; // basis points, e.g. 1000 = 10%
  withholdingRateBps: number; // e.g. 350 = 3.5%
};

type SettlementResult = {
  commissionCents: number;
  withholdingCents: number;
  ownerPayoutCents: number;
};

function calculateSettlement(input: Settlement): SettlementResult {
  const { grossRentCents, commissionRateBps, withholdingRateBps } = input;

  const commissionCents = Math.round((grossRentCents * commissionRateBps) / 10_000);
  const withholdingCents = Math.round((grossRentCents * withholdingRateBps) / 10_000);
  const ownerPayoutCents = grossRentCents - commissionCents - withholdingCents;

  return { commissionCents, withholdingCents, ownerPayoutCents };
}

Working in cents and basis points avoids floating-point rounding drift across thousands of monthly settlements. The function has no side effects, which means it can be tested against the exact cases a tax authority audits: the boundary amounts, the zero-commission edge case, the rate that changes mid-year.

The reporting format is the hard part, not the transfer

Moving money from a tenant to an owner is a solved problem — any payment processor does it. The part that takes real work is producing the reporting format a national tax authority requires, correctly, for every settlement, every month, without a person re-deriving it by hand.

That reporting logic is specific to one country's rules. It changes when regulations change. It is also the part competitors without local tax expertise cannot easily copy, because it is not a payments feature — it is domain knowledge encoded as software.

Closing the loop removes the reconciliation step entirely

The objective is not a faster spreadsheet. It is removing the spreadsheet's job: collection, withholding, commission split, and payout should be one recorded event, not three transfers an agency reconciles against a document afterward.

An agency that manages 50 units and does this by hand is running the same calculation fifty times a month, by hand, with no shared audit trail between the collection and the payout. The fix is not more diligence. It is treating collection and settlement as one operation instead of two things that happen to touch the same money.