Part 3: Receiving entries and calculating and collecting customs revenue

New Zealand Customs Service: Collecting customs revenue.

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.

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

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

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.

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.

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.

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

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

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

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

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).

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.

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.

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.

The business analysts made changes to unique identifiers. These were reviewed within their unit before the changes were published.

Our conclusions

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.

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

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

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.

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.

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

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.

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

We expected that CusMod would correctly calculate the applicable duties for each entry.

Our findings

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.

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).

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.

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

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

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

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.

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.

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

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

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.

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

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.

The information technology disaster recovery plan was last tested in May 2006. This included a full test of CusMod’s software and hardware configuration.

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.

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.

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.

CusMod was available to staff during working hours nearly all of the time, except for planned outages for improvements and testing.


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.

Figure 5.

Source: Adapted from the Service’s information.

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.

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.

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.

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

CusMod was available to staff when they needed it.

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.

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.
page top