Fees and required documents
This lesson covers how a service charges and what the applicant must upload. Both are configured on their own tabs and both can depend on the case type the applicant chooses.
The Fees tab
Open Fees. The first choice is the fee type:
| Fee type | How it works | Pair it with |
|---|---|---|
| Fixed | One fixed amount in Kwacha, invoiced automatically | A Make Payment step |
| Dynamic | An officer adds the fee while processing the case. You choose who: Case Officer or Supervisor | A Generate Invoice / Fees step, then Make Payment |
| Module fee types | Offered only while the module that provides them is switched on, for example a fee worked out from a register | As the module describes |
The fee text on Service settings is only what citizens read on the service passport. The Fees tab decides what is charged. Keep the two consistent.
The fee schedule
The fee schedule lists the lines that can be charged. Each line has a description, a revenue code, optionally a case type, and a basis: a fixed amount, a percentage of a value the applicant declares (optionally capped), or officer-determined. How the platform uses the lines:
- One fixed line: the case is priced automatically at submission.
- Lines with a case type: the line for the type the applicant selects is charged; one matching line prices the case
automatically.
- Several lines: the officer picks the applicable fee at the Generate Payment step.
If the service passport already has a fee text with amounts, the schedule editor can read the amounts from it as a starting point. Check every line it proposes.
One calculation decides the amount charged without an officer, and every channel uses it: online submission, the counter, the POS terminal and the fee calculator on the service passport. What a citizen is told before applying and what the invoice says therefore always agree. Where the office sets the final figure, the calculator shows an estimate.
Case types
Case types such as New and Renewal are defined here, next to the schedule. Each type can have its own fee line, its own required documents and, as lesson 2 showed, its own form.
Finance approval
Under Finance approval you can require that fees worked out by officers are approved by finance before they are invoiced. The officer proposes; an accountant approves. As everywhere on the platform, the proposer cannot approve their own proposal.
Transaction codes
The Transaction codes tab holds the revenue code used when the service's revenue is posted. It is required; ask your finance office for the correct code.
How the citizen pays
When the case reaches a Make Payment step, the platform raises an invoice with ZamPay for the amount the server worked out. The citizen pays from My Workplace or My payments on the portal. The amount shown in the browser is never trusted: a tampered amount is refused, a second payment of the same invoice is recorded once, and the case moves on only when the payment is confirmed. Every fee change is kept in the fee change history.
The Supporting documents tab
Open Supporting documents. Each row is one document the applicant attaches after completing the form:
- Name: for example "National Registration Card (NRC)" or "Proof of address".
- Required: required documents block submission until uploaded; optional ones can be added later from the
applicant's workplace.
- Guidance: a short note, for example "certified copy, not older than 3 months".
- Only for: a document may apply only to some case types.
Officers verify or reject each upload in the case window. Uploads are checked (file type, size, malware scan hook) before officers can verify them.
Choosing documents well
- Ask only for documents the decision needs. Every extra document is a cost to the citizen and personal data the
government must protect.
- Do not ask for a document the government already holds if a register look-up can confirm the fact instead.
- Name documents the way citizens know them.
- Make the guidance specific: what kind of copy, how recent, which pages.
A worked example
For the "Example Vendor Permit":
Fees
| Line | Amount | Case type |
|---|---|---|
| New vendor permit | ZMW 250.00 | New |
| Renewal of vendor permit | ZMW 150.00 | Renewal |
A single fixed amount is not enough here, because the amount depends on the type. The case-type lines price each case automatically at submission from the type the applicant chose. If the ministry instead charges by the size of the site after the inspection, use Dynamic, add a Generate Invoice / Fees step after Inspect Site, and switch on finance approval.
Documents
| Document | Required | Only for |
|---|---|---|
| Copy of NRC | Yes | |
| Lease or letter of consent for the site | Yes | New |
| Previous permit | Yes | Renewal |
Test with synthetic files only, such as a blank PDF named example-nrc.pdf.
Common mistakes
- A Dynamic fee type with no Generate Invoice / Fees step: no one is ever asked to set the fee.
- A Make Payment step with no fee configured.
- Fee lines whose case type does not match any defined case type.
- A required document that applies to every case type when it is only needed for one.
The end-to-end test of the service (taught in the E2E testing and documentation course) pays each fee through the ZamPay test double, so these mistakes are found before citizens meet them.
Check your understanding
- What is the difference between the Fixed and Dynamic fee types, and which step must accompany Dynamic?
- How does the platform choose the fee when the schedule has several lines without case types?
- Why does the platform never trust an amount sent from the browser?
- What does finance approval add, and who may not approve a fee?
- What does marking a document Required do?
- How can a document apply only to renewals?
Sign in to record your progress.
Previous: Modelling the process Next: Output documents and capabilities