> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eosb.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Business rules

> The rules the platform enforces, why each one exists, and the screen where you meet it.

The platform was built to a detailed requirements specification agreed for the EOSB scheme. This page sets out the rules from it that the platform enforces, in plain words, so you know not just *what* happens but *why it has to*. Each rule links to the screen where you meet it.

## Registration and onboarding

| Rule | Why | Where you see it |
| - | - | - |
| One legal employer may hold only one registration. A registration number already on an approved or pending record is flagged as a duplicate. | Stops the same business being registered twice and its liability split. | [Register an employer](/admin/register-employer), [Employer verification](/regulator/employer-verification) |
| An employer cannot be activated until verification is complete. | Only verified organisations may hold employees' benefits. | [Register an employer](/admin/register-employer), [Activation](/employer/activation) |
| Every verification decision is traceable to a named officer, and every rejection carries a reason. | Accountability for who let an organisation in, or kept it out. | [Employer verification](/regulator/employer-verification) |
| An employer cannot use the platform until its status is **Active**. Activation needs the trust, trustee, fund manager and bank account in place. | Benefits must have somewhere safe to go before they start to build up. | [Activation](/employer/activation) |
| There is only **one** official platform trustee and **one** official platform fund manager. Any number of independent ones may be registered. | The official providers serve every employer on the official platform service model. | [Register providers](/admin/providers), [Provider verification](/regulator/provider-verification) |
| Independent trustees and fund managers must hold MELSS accreditation. | Only accredited providers may handle trust money. | [Provider verification](/regulator/provider-verification) |
| All registration data, documents, timestamps and the identity of the person who submitted them are kept. | Audit. | [Register an employer](/admin/register-employer), [Register providers](/admin/providers), [Provider verification](/regulator/provider-verification) |

## Trusts

| Rule | Why | Where you see it |
| - | - | - |
| Every trust has a unique Trust ID and is linked to one employer. | Each trust's money and liability can be traced. | [EOSB trust](/employer/eosb-trust) |
| A trust can only cover employees and liabilities of the employer that controls it. | One employer's money never pays another's employees. | [EOSB trust](/employer/eosb-trust) |
| An employer may have more than one trust, for example for different staff categories or business units. Each is separately governed and funded. | Flexibility for larger employers. | [EOSB trust](/employer/eosb-trust) |
| With one active trust, employees are assigned to it automatically. With more than one, each employee is assigned by hand. | The platform cannot guess which trust a person belongs to. | [Trust assignment](/employer/employees/employee-record#trust-assignment) |
| A trust's assets may pay the benefit of any employee assigned to it. | The trust is one pool for its members. | [Trust assignment](/employer/employees/employee-record#trust-assignment) |
| The trust model chosen when the trust is created (official platform or independent) drives how it is calculated and governed. | | [EOSB trust](/employer/eosb-trust) |

## Employees

| Rule | Why | Where you see it |
| - | - | - |
| An employee belongs to one employer at a time. | A benefit has one employer responsible for it. | [Register an employee](/employer/employees/register) |
| Duplicate identities are checked when an employee is registered. | Stops double registration and double benefits. | [Register an employee](/employer/employees/register) |
| An employee may be registered without a payout account, but must have a **valid** one before a final payment can be made. | Registration should not wait for bank details; payment must. | [Register an employee](/employer/employees/register) |
| Bulk uploads must use the approved template. Valid rows are imported; rows with errors are rejected and reported row by row, and every imported employee keeps a link to its upload batch. | Partial import keeps good data moving; the error report says exactly what to fix. | [Bulk upload](/employer/employees/bulk-upload) |
| Every change to an employee is recorded with the old value, the new value, the time and who made it. | Audit. | [Update employee records](/employer/employees/update-records) |
| Salary and employment-date changes need approval, and trigger a recalculation of the benefit from the effective date. | They change what the employee is owed. | [Update employee records](/employer/employees/update-records) |
| Payment account changes must pass validation. | Money must go to the right person. | [Update employee records](/employer/employees/update-records) |

## Calculating benefits

| Rule | Why | Where you see it |
| - | - | - |
| Benefits are calculated from the approved salary basis and the employment start date. | | [Monthly accruals](/regulator/monthly-accruals) |
| The opening balance is calculated as at the **last month-end** before registration, and stored separately from monthly accruals. | Service before the platform is recognised, and can always be told apart from what accrued after. | [Opening balance](/employer/employees/employee-record#opening-balance) |
| The monthly accrual runs automatically when each month ends: **current cumulative benefit − previous cumulative benefit**. | | [Monthly accruals](/regulator/monthly-accruals) |
| The monthly accrual is the movement in liability, not the final benefit. Both the cumulative figure and the monthly movement are stored for every employee. | | [Monthly accruals](/regulator/monthly-accruals) |
| Every calculation must be reproducible from its stored inputs, parameters and dates. | Any figure can be checked years later. | [Opening balance](/employer/employees/employee-record#opening-balance), [Monthly accruals](/regulator/monthly-accruals) |
| An employee with no valid salary basis is placed in a computation exception queue and their month is not finalised. | Better a visible gap than a wrong figure. | [Monthly accruals](/regulator/monthly-accruals) |

## The liability ledger

| Rule | Why | Where you see it |
| - | - | - |
| The liability ledger is the formal record of EOSB liability. | One source of truth for what is owed. | [Transaction ledger](/employer/transaction-ledger) |
| Every ledger value is traceable to the calculation that produced it. | | [Transaction ledger](/employer/transaction-ledger) |
| History is preserved; nothing is overwritten. | Audit. | [Transaction ledger](/employer/transaction-ledger) |
| Liabilities are classified (live, closed out, settled, disputed, held), and close-out amounts stay distinguishable from routine accruals. | Funding and reporting need to know what kind of liability each amount is. | [Transaction ledger](/employer/transaction-ledger) |

## Termination and payout

| Rule | Why | Where you see it |
| - | - | - |
| The termination date is the cut-off for the final calculation. Once terminated, an employee accrues nothing further. | | [Terminate an employee](/employer/employees/termination) |
| Termination locks further employment changes and triggers the payout process. | The figure being paid must not move. | [Terminate an employee](/employer/employees/termination) |
| Only the **trustee** may approve or reject a benefit payment, confirmed with a one-time code. | The trustee controls the trust's money. | [Approve benefit payments](/trustee/benefit-payments) |
| A payment may only be rejected for **summary dismissal** or a **court order**, with a narrative of up to 250 characters. | A leaver's benefit is a right; refusal needs a legal basis. | [Approve benefit payments](/trustee/benefit-payments) |
| The administrator pays approved benefits, in full or in parts, with a one-time code. **Amount outstanding = amount due − amount paid.** | | [Pay out benefits](/admin/benefit-payouts) |

## Funding

| Rule | Why | Where you see it |
| - | - | - |
| Employer and trust must both be active. | | [Fund your EOSB trust](/employer/funding) |
| Wallet and gateway payments are confirmed with a one-time code that expires after 60 seconds. | | [Fund your EOSB trust](/employer/funding) |
| **Until the payment aggregator has settled the money into the trust account, it does not count as a trust asset** and is not used to measure funding deficits or surpluses. | Money in transit is not yet the trust's. | [Fund your EOSB trust](/employer/funding) |

See [SmartPay e-wallets](/concepts/e-wallets) for how settlement works.

<Note>
  The requirements also describe an **employee self-service portal**, where employees would update their own contact and payment details. It is planned and not available yet; today employers and the administrator make those changes.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.