Ejar contracts: what is in one, and how to run it after signing

A documented lease is not a piece of paper you file and forget. It is the source of every number you will track for the rest of the year: when a payment falls due, how much it is, which unit it belongs to, and when renewal starts. Most of the money small portfolios lose is not lost at signing. It is lost months later, when someone loses track of a payment or misses a notice date.

This guide is written from a specific position: we read documented lease contracts every day and turn them into payment schedules. So what follows is about what a contract contains and how you run it after documentation, not about the documentation procedure itself. For current procedures and fees, always go to Ejar and the Real Estate General Authority. Those change, and they should not be copied out of an article.

What a documented contract actually carries

Open a contract file and you will find it divides into clear groups. The ones that matter operationally:

The parties. Landlord and tenant, by name and by ID or commercial registration. The contract is bilingual, so a name may appear in Arabic only or in English only. If you are building a tenant record, key it on the ID or the CR, never on the name. Names get written several ways. ID numbers do not.

The property and its units. Property number, type, and the units covered. One contract can cover several units, and that single fact is what confuses most schedules later.

The term. Start and end dates, and the number of contract years. Everything else derives from these.

Value and payment schedule. Total contract value, payment frequency, and the amount and due date of each installment. The value in the contract is inclusive of tax where tax applies, which matters when you post it.

Annual escalations. On a multi-year contract, each year may carry a different annual value. Ignore this and your schedule will be right in year one and wrong in year two.

Deposit and fees. The security deposit and any administrative fees. Neither is rental income.

Turning a contract into a payment schedule

The schedule is the operational translation of the contract. The rule is simple: one row per installment, and every row carries a due date, an amount and a unit.

Take a 60,000 riyal contract for one year, paid quarterly. That is four rows of 15,000 riyals, dated from the contract's start date, not from the date it was signed. Sometimes those differ by a day, sometimes by a month, and that difference shows up in every reminder you send afterwards.

Three things manual schedules get wrong again and again:

1. Due dates follow the contract start, not the documentation date and not the first of the Gregorian month.
2. An annual escalation applies to its own year. Divide each year's value across that year's installments, not across the whole term.
3. A deposit is not a rent payment. Post it where it belongs, or the tenant will appear to have paid more than they have, and you will find the gap at move-out.

Multi-unit contracts, where the money actually goes missing

When one contract covers three units, the tenant makes one payment, but your books need to know each unit's share of it. This is not an accounting nicety. Without it you cannot tell which unit is profitable, and you cannot end one unit's lease without disturbing the rest.

The correct approach is to split the payment across units in proportion to what each unit owes, in halalas rather than rounded. The shares must add up to exactly the amount received. Round each share separately and you get a few halalas of drift that accumulate over the year and make a fully settled contract look like it still owes something.

The other common mistake: posting the whole amount against the first unit. The first unit then looks paid and the rest look overdue, so reminders go out to a tenant who has already paid in full.

Four places a portfolio leaks after signing

The payment that arrived and was never posted. A transfer lands and is never matched to a specific installment, so the obligation stays open in the records and closed in reality.

The escalation that was never applied. The contract raises the rent in year two and the schedule is still on year one's figure. The gap surfaces at the annual review, usually well past the point where asking for it is comfortable.

The renewal that passed in silence. The notice date goes by with no alert, so a new year starts on old terms, or a unit sits empty that could have been re-let with no gap.

The forgotten deposit. Nobody remembers the deposit amount until move-out, and then it becomes an argument with no record behind it.

All four share one property: nobody catches them at the time, because nobody is looking. A system that tells you when something is due solves all four. A spreadsheet does not.

From contract to system without retyping

Entering a documented contract by hand takes time and introduces errors: a digit copied wrong, a date read backwards, a unit missed. A portfolio with thirty contracts is thirty chances to get it wrong.

The alternative is to read the contract data straight out of the file. In Aqarflow you upload the signed contract and the parties, term, value, units, payment schedule and annual escalations are extracted for you to review before you commit them. That step is covered on the Ejar contract import page.

What matters here is not the tool but the principle: the data is already in the contract, and retyping it by hand adds no value and plenty of risk.

In short

A documented contract carries everything you need to run the coming year. The difference between an orderly portfolio and a chaotic one is not the contracts. It is what happens after them: whether the contract became an accurate payment schedule, and whether anyone knows a payment is due before it is late.

For the next step, read rent collection: a working method, or if you are comparing systems, start with how to choose property management software.