Part 3: Receiving entries and calculating and collecting customs revenue
3.1
In this Part, we discuss the results of our examination of:
- the Service’s procedures for receiving entries and ensuring data integrity;
- the Service’s controls for manual and electronic data entry;
- CusMod’s business rules;
- how CusMod calculates customs revenue;
- how customs revenue recorded in CusMod is recorded in the FMIS;
- the Service’s monitoring of the customs revenue collected; and
- CusMod’s availability and integrity.
3.2
We subjected parts of CusMod and the FMIS to in-depth scrutiny. We report the
results of our scrutiny and give examples, where practical, to explain the points
we make.
Receiving entries
3.3
The Act makes traders and individuals responsible for accurate and complete
entries. After entries are lodged, the Service must ensure that entries are not
accidentally or maliciously altered. We expected the systems for processing
entries to have enough checks to ensure data integrity.
Our findings
3.4
Automated validation checks occurred before the data from entries was
transmitted into CusMod. About 650 errors can occur, and there were procedures
to respond to them all. Entries could be sent back to traders to be corrected or
assigned to a customs officer for the officer’s attention.
3.5
CusMod validated the amounts entered on entries against tables that contained
exchange rates, tariff and concession rates, and predefined conditions or business
rules data. CusMod checked that traders’ calculations were accurate. It checked,
for example, for currency conversion, customs duties, and GST. If an entry had
errors, it was rejected until the errors were corrected. When an entry was lodged
again, the validation checks were repeated.
3.6
CusMod kept a full transaction history, including the user’s identification and
the time and date of changes. If a user changed a transaction or message, then
CusMod created a new version.
3.7
The Service’s staff reviewed the reports available to them to help identify data
errors or anomalies within CusMod. The purpose of the reports was to help staff
to resolve errors in a timely manner.
Our conclusions
3.8
The Service had reliable and thorough systems to ensure that entries were
accurate and complete, and that any alterations to entries were recorded. We were
satisfied that unauthorised alterations would be discovered.
Controls for manual and electronic data entry
3.9
We expected the Service to have identified and set up security measures to ensure
CusMod’s integrity. We expected those security measures to include restricting
access to critical data tables.
Our findings
Staff access to CusMod
3.10
Providing, changing, or removing a user’s access to CusMod required the use
of standard forms and authorisation by a team leader. All users had unique
accounts and individual passwords. CusMod worked with the network operating
system to authenticate and authorise CusMod users. The Service’s information
technology staff were needed to reset forgotten user passwords. The Service had
formal termination procedures for staff who no longer needed access to CusMod
to ensure that a user’s access was removed without undue delay. The Service
reviewed whether staff still needed access to CusMod every six months.
Changes to exchange rates, tariff and concession rates, and unique identifiers
3.11
We found that only approved staff had access to critical master files for exchange
rates, tariff and concession rates, and related unique identifiers (such as the
abbreviations assigned to countries, airports, and seaports).
3.12
The Comptroller had delegated three staff to update the exchange rates, and tariff
and concession rates. They were the Tariff Co-ordinator, Team Leader Corporate
Support, and Manager, Information Delivery Unit.
3.13
The Tariff Co-ordinator electronically updated the exchange rates in CusMod and
on the Service’s website. Before electronic changes were made, the Team Leader
Corporate Support and, at times, the Manager, Information Delivery Unit, verified
the proposed changes to exchange rates.
3.14
Business analysts handled change notifications that required many changes to
the tariff and concession rate tables. The Tariff Co-ordinator performed random
checks on changes. For notifications that required only a few changes, the Tariff
Co-ordinator updated the tariff and concession tables. However, these changes
were not checked by a second person.
3.15
The business analysts made changes to unique identifiers. These were reviewed
within their unit before the changes were published.
Our conclusions
3.16
Only approved staff were able to make changes to critical master files in CusMod
for exchange rates, tariffs and concession rates, and unique identifiers. The
procedures for updating exchange rate tables and publishing the new rates were
satisfactory.
3.17
In our view, the procedures would be improved if all changes to tariff and
concession rate master files were reviewed, including any changes considered to
be “minor”.
CusMod’s business rules
3.18
We expected the Service to have identified and documented the business rules
needed to meet legislative requirements. We expected CusMod to meet these
requirements.
Our findings
3.19
The Service had identified and documented the business rules (the Business
Rules Document). CusMod was designed to incorporate these rules. We reviewed
selected business rules and found that they were consistent with the Act.
3.20
We tested 15 business rules within the Business Rules Document and found that
CusMod was enforcing 11 of them. Although this indicated a high rate of non-enforcement,
there was no adverse effect on revenue collection.
3.21
The support staff for CusMod were not using the Business Rules Document to
maintain the business rules within CusMod. The Service told us that the Business
Rules Document was written during the design phase when CusMod was
introduced in 1996, and it had not been maintained. The absence of up-to-date
documentation did not impede the Service from dealing with entries, because
staff relied on CusMod’s source code to apply the business rules. As part of testing
the accuracy with which customs revenue was calculated (see paragraphs 3.24-3.29), we tested the logic of some source code and found that it was sound.
Our conclusions
3.22
Although most of the business rules we tested were being enforced, some were
not. The Business Rules Document was not complete or up to date, but this did
not have an adverse effect on customs revenue.
3.23
In our view, it is important that the Business Rules Document be complete and
up to date, to ensure that all staff needing to use it have access to the correct
information. It also ensures that the Service has sanctioned CusMod’s source code
and the practices staff have adopted match the Business Rules Document. There
is a risk that the out-of-date Business Rules Document may be relied on, so the
correct decisions and actions might not be taken. If CusMod were replaced, the
Service would need to corroborate its existing Business Rules Document before it
could be relied on or used in any business case or system design.
Calculating customs revenue correctly within CusMod
3.24
We expected that CusMod would correctly calculate the applicable duties for each
entry.
Our findings
3.25
As discussed in paragraphs 3.4-3.6, CusMod validated the trader’s entry against
various tables and predefined conditions, and automatically populated various
fields.
3.26
The first step in calculating customs revenue is usually to decide the value for
duty. CusMod found the lodgement date and the correct exchange rate, and
calculated the value in New Zealand dollars based on the relevant duty rates. The
duty rates considered any exemptions or other considerations that might affect
the value (for example, diplomatic privileges).
3.27
We obtained one day’s import transactions from CusMod and the same day’s
customs revenue transactions from the FMIS. Our testing showed that CusMod
correctly calculated the duty for each entry, although we did not find any
documented business rules for “duty rate” and “import duty” in the Business Rules
Document.
3.28
Two customs brokers gave us electronic copies of their import entries for
September 2006, and we matched these with information from CusMod for that
month. We tested the calculations on 10 entries (five from each broker), and they
were correct.
Our conclusions
3.29
CusMod correctly calculated the duty owed for each entry. However, not all
of the business rules for calculating duty that should be documented were
included in the Business Rules Document. We found no evidence that the lack of
documentation adversely affected customs revenue.
| Recommendation 3 |
|---|
| We recommend that the New Zealand Customs Service update its business rules for collecting revenue to ensure that the documents are complete and accurate, which includes clarifying the business rules for duty rate and import duty, confirming through testing that CusMod is performing as intended, and taking any remedial action necessary to ensure that customs revenue continues to be correctly calculated. |
Ensuring that customs revenue recorded in CusMod is recorded in the financial management information system
3.30
About 99% of entries are lodged electronically through customs brokers. The rest are
received through the Service’s website or are manually entered by staff. Based on
the information provided, CusMod calculates the duty owed on each entry. CusMod
does not create the invoice for the duty owed. The FMIS does this using information
extracted from CusMod. Therefore, it is important that the customs revenue
information in CusMod is accurately and completely transferred to the FMIS.
Our findings
3.31
The Service produced two daily balancing reports to ensure that the duty CusMod
calculated as being owed was sent to the FMIS. One report came from CusMod,
and the other from the FMIS. The Service put these reports into a third document
in which the data was electronically sorted and compared. This produced a report
of any differences, and the Service looked into and corrected the differences. The
last time the Service found that the reports did not balance was in 2004. We
matched the daily reports for September 2006 and found that they agreed exactly.
3.32
We documented and tested the procedures and controls that the Service
performed to ensure that the data transferred from CusMod to the FMIS was
accurate and complete. We extracted a day’s transactions and successfully
reconciled the two systems.
3.33
At the end of each month, the Service’s finance department produced a report
from the FMIS for the Comptroller showing the customs revenue collected that
month (and for the year to date).
Our conclusions
3.34
The Service’s procedures and controls enabled it to ensure that the CusMod and
FMIS systems reconciled and that customs revenue information was correctly
passed between them and reported to the Comptroller.
CusMod’s availability and integrity
3.35
Because nearly all entries are lodged electronically, CusMod is essential for
customs revenue collection. Traders need 24-hour access to lodge entries. Once
entries are lodged, traders are entitled to expect the Service to ensure that entries
are not lost because of any information technology failure. If losing entries could
not be prevented, we expected the Service to ensure that the quantity of the loss
was the smallest possible to reduce the cost of relodging or recovering lost entries. If entries are not recovered or the data is corrupted, the customs revenue to the
Crown may be adversely affected.
3.36
We expected the Service to make CusMod continuously available to staff during
working hours. Although delays in processing may reduce efficiency, they would
not affect the customs revenue collected. We expected CusMod and its related
systems to be protected from unauthorised access.
Our findings
Disaster plans and CusMod’s availability
3.37
The Service had a documented business continuity plan and information
technology disaster recovery plan. We sighted these plans and other documents,
such as the disaster management plan that described the disaster management
processes and the disaster management team’s responsibilities. The plans and
the documents supporting them had yet to be updated to reflect changes to the
information technology infrastructure, and contact details for crucial people were
incomplete.
3.38
The information technology disaster recovery plan was last tested in May 2006. This included a full test of CusMod’s software and hardware configuration.
3.39
The main server for CusMod, which also housed the FMIS, was in Auckland. The
disaster recovery server was in Wellington, so the Service had the ability to resume
or continue operations if a disaster affected the Auckland server.
3.40
The contingency arrangements for CusMod meant that, if the system failed, in
most cases the Service would only “lose” entries that had been lodged up to 15
minutes before the interruption occurred. Because of the procedures for lodging
entries and confirming their receipt, the Service was able to ask users to confirm
they had receipts for all entries lodged. In this way, lost entries could be identified
and sent again to the Service for processing.
3.41
The company that provided a managed messaging service for the Service (see
paragraph 3.43) also told us that it had disaster recovery procedures for its
critical e-mail servers. The backup systems were activated without users needing
Part 3 Receiving entries and calculating and collecting customs revenue
35
to reboot their workstation or restart their application. The purpose of these
procedures was to prevent entries being lost between importers and the Service. We did not audit these procedures.
3.42
CusMod was available to staff during working hours nearly all of the time, except
for planned outages for improvements and testing.
Security
3.43
Traders and individuals did not have direct access to CusMod. Traders who lodged
entries independently completed the relevant forms, which the Service’s staff
entered into CusMod. Figure 5 shows the path and responsibility for lodging and
receipting entries. Customs brokers’ entries were passed to the Service through a
managed messaging service.
Figure 5
Processing customs entries
This figure shows the path for lodging entries, their receipt by the Service, and their transfer to the FMIS.
Source: Adapted from the Service’s information.
3.44
Customs brokers were assigned a personal identification number and entries
were rejected if they failed the authentication procedures. The Service had
procedures to detect whether messages CusMod received had been altered during
transmission.
3.45
About 70% of customs brokers used a third-party brokerage system that sent
copies of messages to the third-party company’s Australian-based repository,
where they were stored for support and error-management purposes.
3.46
When CusMod received entries from the managed messaging service, a Customs
Response was sent in reply. For the 70% of customs brokers using the third-party
company, the Customs Response was relayed to the Australian-based
site, repackaged (without any change to the data), and sent to the broker. Other
customs brokers received the Customs Response directly.
3.47
To ensure the integrity of messages sent to the Service and to prevent them being
rejected, the trader electronically signed messages using a personal identification
number and encryption algorithm provided by the Service. The signing process
effectively prevented any tampering with the message.
Our conclusions
3.48
CusMod was available to staff when they needed it.
3.49
The Service had disaster recovery plans for all the relevant information technology
systems for which we expected it to have plans. Some information supporting the
plans was out of date or incomplete. The nature and extent of a disaster or system
failure would have varying effects on traders and the Service’s ability to process
entries. In most circumstances, the Service should be able to continue business
without invoking full disaster recovery.
3.50
The Service had in place effective procedures to assure it and traders that entries
were lodged safely and that measures to prevent tampering were effective.
| Recommendation 4 |
|---|
| We recommend that the New Zealand Customs Service ensure that its disaster recovery plans and supporting documents accurately and completely reflect the current information technology infrastructure and the contact details for crucial people. |