Waste accounting and environmental reporting: data model
Waste accounting and environmental reporting: how to design a data model and set up volume discrepancy checks and period closing without losing data.

Why a clear data model is needed for a waste accounting system
Waste accounting and environmental reporting quickly become sources of disputes and fines if data are stored “any way they come.” Usually the problem is not people, but that the system does not record the meaning: what exactly is considered waste, where it appeared, where it is now and on what basis it was transferred.
A clear data model ensures unambiguous answers to basic questions: what waste type it is, its hazard class, which department generated it, where it is stored, under which contract and when it was removed. When these links are missing, volumes start to “wander” between tables and files, and reports are assembled manually from different sources.
The same events repeat in accounting, and the system must link them into a chain: generation, storage and movements, transfer to a contractor, acts and supporting documents. A good data model stores not only numbers but context: unit of measure, date, responsible person, site and source of the record (weighing, calculation by norm, contractor data).
Discrepancies usually arise when “on paper” and “in fact” yield different numbers. For example, the shop reported 1.2 t for the month, warehouse movements show 1.0 t, and the removal act records 1.3 t. Without a proper data model it’s unclear where the error is: classification, units, date, rounding, or that part of the removal belongs to the previous period.
To reduce such situations, the model typically rests on four blocks: registers (waste type, hazard class, sites, counterparties), operations (generation, movement, storage, transfer), documents (contract, request, waybill, act) and balance control (opening, incoming, outgoing, closing).
A separate topic is period closing. This is not just a “ban on editing.” Closing means results for the period are fixed by rules: changes are possible only via an adjustment with a reason, date and audit trace. That way the system preserves history and reports remain reproducible: today and in a year you will get the same results for the closed month.
Key terms: what exactly to store in the system
To prevent waste accounting and environmental reporting from turning into manual reconciliations, agree on terminology from the start. A common failure is not in the report but in data meaning: the same object is named differently and reference data and operations get mixed up.
Waste type — a register card. It typically records the name, code (by company or regulator classification), base unit (kg, t, m3), aggregate state (solid, liquid, paste-like, gaseous) and, if needed, composition or handling notes. The unit should have one “primary” value, and conversions (e.g., liters to kg) are better formalized as a rule, not free text.
Hazard class also lives in a register, but decide what to link it to. Most often the hazard class is tied to the waste type and operations inherit it. If the class can change after analyses, make it a separate entity: a “batch passport/analysis” with a date and supporting document.
Place of generation and place of storage are different. Place of generation answers “where the waste originated” (shop, section, office, laboratory). Place of storage is “where it is physically located now” (container site, warehouse, temporary storage). One section can generate waste that is stored on a common site.
To avoid mixing operations and state, it’s convenient to separate concepts:
- waste batch — a specific volume generated on a specific date (or period) linked to a type, generation place and responsible person;
- movement — any change in a batch’s state: transfer, handover, write-off, removal;
- balance — the calculated value at a date by storage location and waste type;
- supporting document — proof of movement (waybill, internal order, act).
A simple example: the laboratory generated 20 kg of reagent waste (a batch), it was moved to a temporary storage area (movement), and at the end of the day the site shows 120 kg (balance). This separation helps detect discrepancies and correctly close periods without rewriting history retroactively.
Registers: waste types, hazard classes, sites and counterparties
Registers are the foundation; without them waste accounting and environmental reporting quickly become a set of unconnected tables. When registers are orderly, documents (generation, movement, removal) are filled consistently and reports reconcile without manual fixes.
Waste types
For each waste type record not only the name but how the system should handle it. Minimum: classifier code, name, default hazard class and accounting unit (kg, t, m3). If volumes are practically counted in m3 but reporting needs mass, define a conversion rule up front.
A practical register card usually needs 3–5 attributes: code and name, default hazard class (editable in operations), unit and conversion coefficient/density, a flag for «sent for recycling/disposal/treatment», and short labeling requirements.
Hazard classes
Maintain hazard classes as a separate register rather than a number in the waste card. Then attach storage requirements as attributes: need for sealed containers, whether open containers are allowed, restrictions on co-storage, required protective equipment. This helps both operations and inspections.
Sites and places of generation/storage
Structure places as people actually work: organization -> branch/site -> section -> specific place (warehouse, container area, temporary accumulation site). This allows the same waste type to be tracked separately by address and responsible person.
Counterparties and user roles
Differentiate counterparty roles: carrier, recycler, landfill, laboratory. Store tax ID (BIN/IIN), permit details (if applicable), contacts and service types in the counterparty card.
Also configure users and roles separately: who enters primary data, who checks, who approves acts, who can close the period and make adjustments. Agree this before launch; otherwise month-end will bring disputed edits. In practice integrators like GSE.kz often start projects by defining roles and responsibilities so accounting is controllable and auditable.
Operational entities: generation, storage, movements and balances
Operational entities let the system answer the simple question: where and in what volume are wastes right now, and how did they get there. If you mix them into one journal, it becomes almost impossible to explain reporting discrepancies.
Generation
“Generation” is the primary event. It records the appearance of waste on a specific date and place. It’s usually linked to a source: operation, section, shop, office, laboratory.
Practical minimum fields: date (and shift if relevant), place of generation, waste type and unit, volume (with precision and rounding rules), source (department/equipment/operation).
Storage
“Storage” describes a storage object: container site, warehouse, room, tank. Important attributes are limits and constraints: capacity limits, regimes, responsible person, status (available/closed/under reconstruction). This is needed for control of exceedances and to link inventories.
Movements and batches
Treat “movement” as a ledger of postings rather than an editable balance table. That way you always see what changed a quantity. It’s often useful to introduce the idea of a batch (lot) — a bundle of origin and properties that can be moved or written off.
Typical movement operations: receipt into storage (from generation), transfer between storage places, write-off/removal (by act), inventory adjustment, return/re-sorting (if applicable).
Balances: calculated and physical
Balances are best calculated automatically: for each storage point and at period end (opening + receipts - issues). Separately record physical inventory balances to see differences and reasons.
Example: a section generated 120 kg, but 118 kg arrived at the site due to conversion to different packaging. This should appear as a separate movement, not as an “edit” of the original generation.
Attachments not tied to a single document
Store passports, protocols, photos and scans as attachments that can link to different objects (waste type, storage place, batch, act). One passport can be reused in multiple records without duplicating files and while keeping history.
Contracts and acts: how to link removal to actual volumes
To avoid removal turning into a pile of scattered scans, link the contract and the act to what was actually accumulated at storage points. Then the system can answer: what volume was removed, from where, under which basis, and how balances changed.
In a contract card record validity period, counterparty, permitted waste types and limits (if any), collection points and tariffs. Store not only a general limit but linkage to waste type and unit — otherwise plan-vs-fact comparison is hard.
Between a contract and an act it is useful to use an intermediate document — a request (route) for removal. This is the plan: date, storage place (or generation place), planned volume, transport, responsible person. A request helps agree removal before the fact and prepare batch selection.
An act or waybill records the fact. It should include date, number, parties’ details, signatures and actual volumes per line. Each line should reference a specific batch (or set of batches) and storage place so the system reduces the balance exactly where the material was.
How to make the link to balances reliable
A simple rule: do not allow an act to be posted until the write-off source is specified (batches and places) and the actual volume is checked against available balance.
Example: the warehouse accumulated 1.2 t of Class III waste, the request lists 1.0 t, and the act records 1.3 t. The system must either block posting or require an explanation and a corrective document.
A short status flow disciplines the process: “Draft” -> “For approval” -> “Approved” -> “Posted” -> “Canceled” (with reversing movements).
Where discrepancies most often arise
Causes are usually mundane: different units (kg vs t), rounding, mixing storage locations, or an act linked to a contract but not to batches. Before closing a period, automatically search for such cases: acts without write-off sources, fact > available balance, fact far from plan, drafts in the closing month.
Step-by-step: how to implement waste accounting in an information system
Start with organizational boundaries: where waste is generated and who is responsible. Without that, registers and documents will quickly become a “dump” of records no one can verify.
Minimal implementation plan
-
Collect a list of sites, generation places and storage places, plus responsible persons. Agree who records events and who verifies them.
-
Load the waste type register and check units. The most common problem is different units across divisions (kg vs t, liters vs m3) and inconsistent conversion coefficients.
-
Configure roles and approvals: input (site responsible), verification (environmental/OHS), approval (manager or authorized person). After approval a record should not be silently rewritten.
-
Describe operations as they occur in practice: generation, transfer between storage places, removal, inventory. For each operation define which balances change and which documents confirm it.
-
Fix mandatory fields for posting: date, site, waste type, hazard class, quantity, unit, responsible person, supporting document (act, waybill, route sheet). Add change logging and a mandatory reason for adjustments.
Small example
At the “Polyclinic” site used lamps are generated. The responsible person records the generation and places them in storage “Hazardous waste warehouse.” The environmental specialist checks that the waste type and hazard class are selected correctly and that units match what will be on the removal act.
If you build discrepancy checks and a clear period closing rule from the first weeks, accounting becomes predictable: you see where a number came from, who confirmed it and why it changed.
Discrepancy checks: where errors usually appear
Accounting errors usually arise at seams: different departments, different documents, different units. So checks should follow movement logic: what was generated, where it is stored, what was removed and what remains.
A basic check is a balance by storage location and waste type. For each period the equation should hold: opening balance + generation + inward transfers - removals - write-offs = closing balance. If it doesn’t, the cause is usually a missing operation or a document posted retroactively.
Another common source of discrepancy is units. If generation is recorded in kg and the removal act is in tonnes without an explicit conversion coefficient and source (waste passport, scale, density calculation), such entries are better blocked than silently converted.
Typical situations: incomplete document chains (act without request or contract, or vice versa), lack of plan-fact reconciliation, negative balances (removal done before generation or transfer), exceeding limits (contract, storage or retention period), or errors in hazard class or waste type.
Practical step: set an allowable deviation between request and act (percent or absolute) and require a reason if exceeded. Also ensure each batch and storage place balance cannot go negative.
Period closing: rules, exceptions and adjustments
Period closing is the point after which monthly (or quarterly) figures are considered confirmed and ready for reporting. The system must record the period, the complete set of posted documents and calculated balances for each waste type, generation place and storage place.
At closing, results are usually “frozen”: how much was generated, how much moved, how much removed by acts, and which balances carried forward. It’s useful to save calculation parameters (units, conversion coefficients, rounding rules) so later you can explain why values look that way.
After closing: what is forbidden and what is allowed
Basic rule: after closing you cannot post backdated documents without a controlled procedure. Otherwise balances and results will jump.
Typical constraints: documents dated in a closed period are blocked for regular users; only adjusting documents with a reason and approval are allowed; any change affecting volumes requires recalculation of balances for the impacted interval; recalculation is initiated by a limited set of roles; the recalculation result is recorded as a separate event with date and initiator.
Example: January was closed, and in March an act is found that actually belongs to January 28. Instead of just posting the act, the system should require an adjustment document with a reason (e.g., original arrived late) and recalculate balances from January 28 to today.
Adjustments and change reports
An adjustment should be a separate entity: what was corrected, which primary document it relates to, how volumes changed, and who approved. This prevents unnoticed edits and helps during inspections.
A post-closing change report is useful: a list of adjustments and their impact on period indicators. Store that report with the closing record so history can be restored without manual reconciliation.
Environmental reporting: which results the system should collect
Environmental reporting is usually built around simple questions: how much was generated, how much remains in storage, how much was transferred (removed) and where. If reporting uses the same data as accounting, final numbers come without ad-hoc spreadsheets.
Results must be computed by the necessary dimensions: site (generation and storage), waste type, hazard class, counterparty (carrier and/or recycler), period. For internal control add breakdowns by department and responsible person.
For reporting and management checks the system typically needs aggregates: generated during the period, transferred (removed) during the period, opening and closing balances; turnovers by contracts and acts; unit reconciliations and conversion coefficients with their source.
Crucially, there must be traceability: each summary row should link back to primary records. A user should be able to open a figure “removed 12.4 t,” drill into a list of acts, then into a specific batch with date, site, storage place, transport and responsible persons.
Also keep data quality indicators: share of records without storage place, without contract, without act, with empty hazard class, or suspicious unit conversions. They quickly reveal why a report “doesn’t add up.”
For export, predefine fields regulators and auditors usually require: waste code and name, hazard class, site (codes and address), period, unit, conversion coefficient, mass/volume, contract number and date, act number and date, counterparty (BIN/IIN), destination, handling method, author and timestamp, document status and period-closed flag. Then an export can be generated automatically.
Common mistakes in design and implementation
Major problems stem not from complex formulas but from small early decisions. They later turn into duplicates, “floating” balances and disputed numbers.
No unique identifiers and naming rules
If waste types and places are created “as they come,” after a few months you get “Used oils,” “Oil waste,” “Waste (oil)”, and no one is sure they are the same. The same happens with storage places when one warehouse is entered multiple times.
Enforce mandatory fields: record code, unit, linked hazard class, active flag (instead of deletion), uniqueness rules by key set (e.g., code + organization + site).
Mixing roles and no period closing control
If the same person can create an operation, confirm it, post an act and close the period, errors become “official.” Worse if closing is formal and does not block changes.
Separate roles: input, verification, approval, closing. After closing allow only adjustments via a dedicated document with reason and date.
No regular inventory and balances live apart
Without inventory the system drifts from reality. For example, generation is recorded daily while removals are posted monthly. If you don’t reconcile site balances, “on paper” waste can accumulate infinitely or go negative.
Set a clear rhythm: monthly balance reconciliation by sites and targeted checks for volume discrepancies.
Acts and contracts stored only as files without structure
If the removal act is attached only as a PDF you cannot automatically verify that the volume matches accumulation at the removal date and that the removal is under the correct contract.
Minimum structure for an act: counterparty, contract, date, site, waste type, volume, unit, document number.
Corrections by deleting records
Deleting “to fix” breaks history and makes audits impossible. Prefer adjustments as separate documents, versions and stated reasons.
Short rule for implementation: first define data rules and roles, then input forms, and only after that reporting.
Short checklist and next steps
Before launch ensure accounting relies on simple rules the system can check itself.
Minimal readiness typically looks like: waste type register includes unit, hazard class and conversion rules; each generation event is linked to a place and responsible person; removal is confirmed by an act linked to a contract; balances are calculated from movements and do not go negative; tolerance checks and a correction protocol (who, when and what changed) are configured.
Agree on period closing in advance. For healthcare organizations it’s convenient to close the month on the 3rd working day: after that operations cannot be changed, but adjustments are allowed via a separate document with a reason (reweighing, late act, unit correction).
Proceed in short iterations: pick one waste type and one site and run the path “generation -> storage -> removal -> act” through to reporting; enable discrepancy checks (act must not exceed available balance, plan-vs-actual must fit tolerance); configure roles and responsibilities; document the post-closing correction procedure; fix the output format for reporting and reconcile it monthly.
If there’s no internal team for design and implementation, engage an integrator experienced in industrial and government deployments. In Kazakhstan such projects are often led by companies like GSE.kz: they combine system integration and support, helping embed data control, roles and period closing into the operational loop from the start.
FAQ
Where should I start the data model for waste accounting to avoid chaos later?
Start by separating reference data and operations. Reference data answers “what it is and where it occurs” (waste type, hazard class, sites, counterparties), while operations record “what happened and when” (generation, movement, removal, adjustment). Then numbers are calculated from movements, not manually rewritten in balances.
Why store place of generation and place of storage separately?
Because “where it appeared” and “where it currently sits” are different managerial facts. If you mix them, you won’t be able to explain discrepancies between the workshop, the warehouse and the removal act, nor correctly calculate balances by storage points.
Is it better to tie hazard class to the waste type or to the batch?
Usually attach the hazard class to the waste type as a default value to reduce input errors. If class can change after lab analysis, create a separate entity for analysis/lot passport with a date and supporting document; operations then take the class from that record.
What is a “waste batch” and why is it needed in the system?
A batch is a specific volume that originated on a particular date (or period) at a particular place and with a responsible person. With batches you can unambiguously record where removals are taken from, track movements, and preserve history when making adjustments.
How to set up units and conversions (kg, t, m3) correctly?
Choose one base unit per waste type and record it in the register. Conversions (e.g., liters to kilograms) should be implemented as a rule with a coefficient and a source for that coefficient, so it’s clear why the mass was calculated that way instead of being “recalculated ad hoc”.
How to link a removal act to actual balances so there are no negative balances?
Require that the act cannot be posted without specifying the source of the write-off: specific storage location and batch (or set of batches). The system should also check available balance as of the date and not allow writing off more than is recorded without a separate adjustment and reason.
Which volume discrepancy checks should be enabled first?
At minimum, control the balance: opening balance + generation + inward movements - removals - write-offs = closing balance for each waste type and storage location. Also check acts without a write-off source, large plan-vs-actual deviations, mismatched units between generation and removal, and drafts in the period being closed.
What should “period closing” mean in waste accounting besides blocking edits?
Closing the period records results and makes them reproducible: today and a year from now you should get the same numbers for the closed month. After closing, ordinary users must not change documents back-dated to the period; corrections are only allowed via a separate adjustment with a reason, approval and audit trail.
How to make corrections if an error is found after the month is closed?
Do not delete or overwrite primary records. Create an adjusting document that states what changed, by how much, why and to which primary document it refers, then recalculate balances for the affected interval and record who initiated the recalculation and when.
What roles and access rights are needed for manageable accounting?
Split roles into at least “input”, “verification”, “approval” and “period closer” so one person cannot complete the entire cycle without oversight. This reduces disputed edits at month end and helps inspections because it’s clear who entered data, who confirmed it and on what basis.