Attachment “J”
Trade Comments regarding Edit-Lite
for the Automated Commercial Environment (ACE)
TSN Transition Committee
September, 2007
Executive Summary
On behalf of the TSN trade community, the Transition Committee wishes to express its concerns with regard to the current proposal for the reduction and elimination of the edits and validations currently performed in the ACS system during the development of ACE.
The general rule of programming a new system is to deliver a replacement which is "as good as or better than" the original system. We are concerned that any changes which reduce functionality of the current process would be counter productive to the usefulness of an automated system, placing additional burdens on both CBP and the trade.
Of particular concern is the identification of the specific edits that would be eliminated. The conception of ACE was accompanied by public concern regarding the cost to the trade to implement any new systems. At that time, CBP communicated that the cost to the filing public would be minimal. The current concern is that lack of sufficient edits may increase these costs significantly since the elimination of the 'edits' within ACE may result in considerable efforts to program future changes for of all importing systems within the trade. Whereas CBP is concerned with the economic impact of one system, the filing community has numerous systems which interface with ABI. The vast majority of filers are small to medium size companies, and this would prove to be a major burden to them.
Background
Currently, CBP has 1,468 error messages listed in the ABI Error Message Dictionary. These edits are currently being used by ACS. CBP is discussing implementing a reduced set of edits and validations that they called “Edit-Lite”. Edit-Lite would consist of minimal edits that ensure that codes used within the Entry Summary message would be valid codes. Any edits that make sure that the data is valid within context of the entry summary will be eliminated. For example, there will no longer be edits in place in the case of safeguard quotas to catch entries filed as type 01 even though the HTS number and C/O that are transmitted are subject to quota.
CBP Software/systems have evolved into a (2) tier checks and balances environment. Software originated audits coupled with CBP originated audits result in higher entry compliance upfront, and reduces 'downstream' costs for post-audit compliance checks for both Trade and CBP.
Examples of Edits:
The following are examples of the edits that will not be performed with Edit-Lite. Some may have an impact on revenue while others affect the statistics being compiled from the entry summary data.
1) Total Payable ADD/CVD does not match CBP’s Calculation
2) Additional HTS Numbers are missing
3) Duty Not Allowed – Tariff Duty Free
4) Duty Computation Date > 60 days in the Future
5) GSP Claim Invalid for This Tariff
6) Incorrectly Estimated MPF Maximum
7) MPF Not Allowed – Set Component
8) Mail Fee Missing
9) License/Certificate/Permit Code Missing
10) Export Date cannot be > Filer Entry Date
11) Value exceeds informal limit for Article
12) Broker Invalid for District
13) Formal Quota Entry Required
14) Agr Cheese License Amount Exceeded
15) Country/Case Number Mismatch
The Mod Act
According to the ACE FAQ document, one of the primary reasons CBP needs to enhance its current computer system is because "a number of laws enacted in the past decade require government agencies to become more effective and cost efficient. ACE is the foundation that will help CBP comply with those laws and regulations, and meet the challenges we face today. "
As we all know, on December 8, 1993, Title VI of the North American Free Trade Agreement Implementation Act (Pub. L. 103-182, 107 Stat. 2057), also known as the Customs Modernization or “Mod” Act, became effective. These provisions amended many sections of the Tariff Act of 1930 and related laws.
Two new concepts that emerged from the Mod Act are “informed compliance” and “shared responsibility”. In order to maximize voluntary compliance with laws and regulations of U.S. Customs and Border Protection (“CBP”), the trade community needs to be clearly and completely informed of its legal obligations. Accordingly, the Mod Act imposed a greater obligation on CBP to provide the public with improved information concerning the trade community's rights and responsibilities under customs regulations and related laws. In addition, both the trade and CBP share responsibility for carrying out these requirements. For example, under Section 484 of the Tariff Act, as amended (19 U.S.C. 1484), the importer of record is responsible for using reasonable care to enter, classify and determine the value of imported merchandise and to provide any other information necessary to enable CBP to properly assess duties, collect accurate statistics, and determine whether other applicable legal requirements, if any, have been met. CBP is then responsible for fixing the final classification and value of the merchandise.
Based on this information, the driving force behind ACE is the Mod Act. Per the Mod Act, CBP has a greater obligation to provide information - as in the example of 'system edits'. The trade has the responsibility to act on this information. Lack of appropriate 'system edits' is in direct conflict with the goals of both the Mod Act and the intent of ACE.
The Mod Act talks about shared responsibility - it is not a one sided responsibility. CBP has a responsibility to all of its clients - including government agencies and the trade - to deliver the same functionality that is in ACS today. Looking back to all the Trade Support Network (TSN) meetings, this was always a premise of the whole program - today's functionality improved with a new system. There was never any discussion about not delivering today's functionalities. There was always disucssion about how to expand today's functionalities in the new environment.
CBP rightly points out that it’s the trade’s responsibility, under the Mod Act, to do things right. In a way, it’s an “entitlement” situation like you find with welfare or tax subsidies for business. Everyone’s used to the edits and relies on them.
But on the other hand, CBP has a responsibility to manage the process effectively, and exercise good governance. These edits are a proven enhancement to the agency’s abilities to enforce trade laws and facilitate legitimate trade. With reduced edits, CBP resources would be strained and their mission effectiveness would be compromised. ABI representatives will have to field many more calls from filers with confusing problems, where the filers previously would have gotten error messages from the edits and fixed the problems up front. Also, inspectors, entry spcialists, and import specialists will be spending much more time chasing down “false positives” based on these preventable errors, taking them away from more important tasks.
In the case of the “Edit-Lite” proposal, the terms “informed compliance” and “shared responsibilities for reasonable care” are being re-interpreted to fit the desire of management to speed up production of ACE. To be sure, we the trade would like to see a faster development, but not at the expense of the completeness of the system. This is especially important since these edits are known to already exist. To realize the need for decomposition of the existing edits and to learn of the time and cost of doing that decomposition at such a late stage in the development process, is not a problem in going forward with the project. It is a problem in the management and planning of the system from the beginning. These edits, especially the more sophisticated ones, are the essence of the system. It is what assists brokers and self-filers in complying with the regulations, not to mention the assistance the edits provide CBP in enforcement procedures. The edits also make it much more difficult for those who might want to (and there are some, although few) who want to circumvent up the system.
Effect of Edit-Lite:
(1) The Broker will face an increased liability risk. 'Discoveries of error' will occur more frequently after the fact, rather than during the original filing because it will require CBP compliance auditing to discover errors.
(2) The Trade will be exposed to higher risks of penalties for non-compliance. Errors & Omissions insurance rates will skyrocket. There would also be additional adjudication of problems and debate as to whether the problem was overt or accidental. If a mistake occurs due to a dropped edit there certainly will be those who might think it was on purpose vs. the feeling it was an oversight. Obviously the number of times things happen can play a role in the adjudication, but not without a lot of rhetoric or even legal action.
(3) CBP man-hour requirements for post audit compliance, collections and corrections will skyrocket. It would follow that if some edits are dropped, it would require a significant increase in requests for amendments to the entry (currently SILS, etc.) In addition, it would likely create many more protests due to omissions and commissions at the original entry summary. Since these types of submissions have to have manual intervention, it would greatly increase the workload on CBP. Has a downstream user study been done? Is there an understanding of how elimination of these system edits will affect internal CBP users? The targeting center data? OGA data? Trade Statistics? Import Specialists Review and Entry Team work loads? The enforcement teams? Audit Divisions looking at data instead of true compliance and oversight issues?
(4) CBP will not benefit from the software in the way that they would if ACE were developed with all of the edits. They will require more personnel to actually sort through the data that will come in “raw” form to ensure that it is accurate. CBP will not have a confidence in the system to have sorted these issues out before it gets added to their desk. So in essence, the money diverted from full development of ACE will go into more entry and import specialists to do the hard edit check that the ABI system does now.
(5) CBP import specialists and entry specialists will require more training on data formats and calculations that are automated in the current environment. In complex duty calculation or entry errors today, a broker normally has to go through a few layers at CBP to get to someone who can actually complete the manual processes, figure out the correct answer, and work their way back from there to find a system or entry error. This will be the norm for all problems and issues now. While we have faith that most ABI reps would be able to get to the root of a system issue to assist, at what point will their expertise be brought in? Will they then have to become a resource internally for CBP to assist with something that was once far more automated and need to be manually checked now?
(6) The fewer edits of Edit-Lite will likely lead to a high volume of data inaccuracies that will limit the statistical products Census can produce for other PGA’s and data users. The U.S. Census Bureau processes around eight million ABI entry summary lines per month to produce very detailed statistical products, so it needs to ensure uniformity and accuracy in trade reporting. It relies on both CBP and Census edits in ABI to effect such reporting. The Census edits are a minor portion of the editing, and they deal with identifying highly questionable data often due to misclassification and keying errors. The major editing done by CBP is critical for Census statistics. The CBP edits prevent impossible data, and check for misreporting of transportation data, Trade Act data, etc. Note: The “Census Edits” will most likely be included in the Edit Lite scenario.
(7) This flies in the face of US National Security Initiatives. We are engaging in the promotion of a 10+2 strategy, the CSI, etc. Programs that all focus on a pre-audit strategy, with CBP in the driver's seat. Now with entry processing, CBP is going to reverse this completely by counting on software developers and brokers to get it right, and worry about it after the fact.
(8) Application Development for future rules and trade programs will not be uniform throughout the trade. Each software vendor will be interpreting the CBP reporting requirements independently. The CATAIR only provides guidelines to format records. CBP will be required to enhance the documentation that is currently provided with each CATAIR change. The trade will need specific examples of all business rules being removed for all entry types possible. This documentation must be kept up to date by CBP as a tool for trade compliance. Many ABI vendors/self-programmers use the ABI testing port to understand the correct record layouts by performing several trials. After ACE, the vendors/self-programmers would not be able to perform tests of entries on ACS using the test port because virtually all entries will be accepted. CBP will need to provide the trade with detail examples of how the records for different business scenario would be laid out for existing and new changes. For example how watch or knife sets, chapter 99 and other secondary tariffs are reported and to which line the duty/ value goes for each tariff in a multi tariff scenario etc.
(9) The cost of software development for trade will skyrocket as software vendors have to raise prices due to their increased costs of development and on-going edit updates. Many software vendors employ Licensed Customs Brokers to ensure that they comply with the intent of the changes. Those vendors that do not will need to consult with Brokers or Customs Attorneys to ensure that their software contains all of the possible edits so that their software can catch problems before they can be sent to CBP.