Every organisation believes its rules are unique. Half-day entry here, Belgian VAT there, invoice numbering per legal entity, a second approver above a certain amount. In many tools each of these quirks becomes a development ticket or, worse, a workaround kept in a spreadsheet on the side.

AlibeeZ starts from the opposite observation: most of these specifics are already known, because they recur from one consulting firm to the next. So they ship in the product as business rules: over 400 behaviours you switch on and tune through configuration. The panel above shows a sample of sixteen, across three domains.

What a business rule is in AlibeeZ

A business rule is a configurable product behaviour: how time is entered, when an invoice may be issued, the threshold above which an expense needs a second approver. These rules are not options to be built for you: they ship and they are tested. Your job is to choose and tune, not to write a specification.

In practice, a rule almost always takes one of these shapes:

  • A choice among a few values: day, half-day or hour; time-and-materials, fixed price, milestone or progress.
  • One setting resolved differently by country, entity or balance: a VAT rate per country, a public-holiday calendar per location.
  • A quantity against a threshold: an envelope 82% used when the alert is set at 80%.
  • A condition and what it triggers: above this amount, this approver.
  • A format: the structure of an invoice number, entity, year, sequence.

What the panel shows: sixteen rules, three domains

Each domain in the panel opens on a picture of its first rule, then lists the others with their setting. The values shown are examples, not a client’s configuration.

Time, absence and leave

Entry and its controls, entity by entity, country by country. The entry unit is chosen between day, half-day and hour (the panel shows half-day); in the product it can even be set activity by activity, down to the quarter-day or a work unit. Leave balances are defined per agreement and per entity, and public holidays follow one calendar per country of operation. The timesheet vs absence check can be blocking, a mere warning, or switched off. Finally, entry reminders are staggered: the employee after two days, their manager after five. There is no period close locking entry: these reminders are what bring the timesheets in.

Invoicing and contracts

One engine for time-and-materials, fixed price and everything in between. The billing model is chosen between T&M, fixed price, milestone and progress. VAT is set per country, entity and service type. For currencies, the rate used is the one on the invoice date, and it is kept afterwards. Payment terms (due date, penalty, early-payment discount) are set contract by contract. Invoice numbering has its own format and sequence for each legal entity. And an overrun alert fires when the envelope crosses the threshold you set.

Projects, margins and purchasing

Profitability computed continuously. The forecast margin is computed from the quote and recomputed on every entry. The forecast vs actual variance carries an alert threshold, per project and per activity. Purchase approval picks the approver from the amount and the cost centre. Expense rebilling is done with a margin, at cost or at a flat rate, depending on the contract. And staffing rules set the criteria that surface an employee for an assignment: required skills, availability, priority.

Tune, try, then go live

A rule is set without development. Configuration is included in your subscription, and business rules stay in your hands as long as things stay within configuration. Beyond that, the need is scoped with our teams, and you know before committing whether it is configuration or quoted development.

Above all, nothing reaches production blind. A rule change can first be deployed on a test base loaded with your own data. You handle it under real conditions: a timesheet entered on a day of leave, an invoice in a foreign currency, an expense above the threshold. You sign it off, or you ask for an adjustment.

Configuring the foundation is part of deployment, which is counted in weeks (under a month at Zenika). The rest is refined afterwards, once you see the product running on your own data.

A rule applies the same way everywhere

A rule that only held on screen would be a rule you could get around. In AlibeeZ, business rules apply the same way to what is entered in the interface and to what comes in through the API. A write through the API goes through the same checks, your business rules, your approval chains, your configuration: what the screen would refuse, the API refuses too.

The consequence is practical. If an in-house tool pushes time entries into AlibeeZ, the timesheet vs absence check applies to it just as it does to an employee. And a rule you change tomorrow applies to both the same day, with nothing to redeploy on the integration side.

The same goes across your entities. AlibeeZ handles several entities, currencies and countries, each with its own rules: the VAT, numbering, public holidays or leave balances of the Belgian subsidiary are not those of the parent company, and they do not have to be.

What it changes

  • something specific to your organisation becomes a setting, not a development project;
  • a setting is tried on your own data before it reaches production;
  • the rule holds for everyone, on screen and through the API, in each entity with its own parameters;
  • the workarounds kept on the side, in a spreadsheet or in one person’s memory, disappear.

Going further: rules say how the product behaves, the article on approval workflows shows how they chain into approval processes, and the one on billing models covers the invoicing domain in depth. For the underlying question of configuring versus building, read our analysis of configuration and custom development.

Frequently asked questions

What does “over 400 business rules” actually mean?

They are configurable product behaviours: how time is entered, when an invoice may be issued, the threshold above which an expense needs a second approver. They ship and they are tested; you switch them on and tune them rather than building them.

Can we change a rule ourselves?

Yes, as long as it stays within configuration, which is included in the subscription. If your need goes beyond it, it is scoped with our teams, and you know before committing whether it is configuration or quoted development.

How do we test a rule before applying it?

The change is deployed on a test base loaded with your own data. You handle it under real conditions, and nothing goes live until you have signed it off.

Do rules apply to data sent through the API?

Yes. A write through the API goes through the same checks as the interface: your business rules, your approval chains, your configuration. What the screen would refuse, the API refuses too.