Most order systems store one boolean for cross-border shipments, something like is_international, and then let a human figure out the paperwork. 19 CFR part 143 does not behave like a boolean. It keys three different things off three different facts, namely which class of entry is available, who is permitted to sign it, and which document has to exist. A single flag cannot carry that, which is why the same column produces so many surprises at a port.
Three facts, three columns
create table inbound_shipment (
shipment_id text primary key,
entered_value_cents bigint not null, -- value of the portion being entered
landed_at timestamptz, -- carrier event, not purchase order
party_role text not null check (party_role in
('owner','purchaser','consignee')),
broker_designated boolean not null default false,
entry_class text check (entry_class in
('formal','informal','none_yet')),
entry_form text check (entry_form in
('cbp_368','cbp_368a','cbp_7501','electronic','invoice_with_declaration')),
declared_at timestamptz
);
entered_value_cents is where the modelling habit goes wrong first. The $2,500 figure in 143.21 applies to a shipment, and the same section reaches an installment arriving at a different time plus a separable portion of one consignment under 141.52. So the number that matters is the value of the piece being entered, not the value of the container it came off. A column fed by a purchase-order total will be wrong for exactly the consolidated inbound flows that make consolidation attractive.
landed_at is the second one. 141.5 sets the deadline at 15 calendar days from landing off a vessel, aircraft or vehicle, or from arrival at the destination port where goods moved in bond. Calendar days, and the trigger is a carrier event. If your only date is when the goods were bought or when they shipped, the deadline cannot be computed at all, and a null here is the honest answer until a carrier feed fills it.
The signer is not a constant
143.26 splits by band, and the split changes which of your own parties can act.
// 19 CFR 143.26, read as a guard rather than a lookup.
export function maySelfEnter(role: 'owner' | 'purchaser' | 'consignee', valueUsd: number) {
if (valueUsd > 2500) return false; // outside the informal bands in 143.21
if (valueUsd > 800) return role === 'owner' || role === 'purchaser';
return true; // owner, purchaser or consignee
}
In the band above $800 and up to $2,500 the permitted filers are the owner and the purchaser, or a broker licensed under 19 U.S.C. 1641 acting on a designation from owner, purchaser or consignee. Below $800, with 19 U.S.C. 1321(a)(2) satisfied, the consignee is added to that list. A warehouse that receives as consignee therefore sits on different sides of that line depending on a value it does not set, and a system that models "who can file" as one role constant will keep getting that wrong.
Both paragraphs carry the phrase using reasonable care, which attaches to the person signing. That is a standard rather than a field, but it has a data consequence, since reasonable care is easier to demonstrate with a document trail than with a recollection.
Eligibility is revocable, and mergeable
Two sentences in 143.22 break any pure decision table. A formal consumption or appraisement entry can be demanded for any merchandise on three grounds, namely admissibility enforcement, revenue protection, or the efficient conduct of customs business. Shipments for one consignee at or under $2,500 can also be pulled together onto a single formal entry.
create table entry_decision (
shipment_id text references inbound_shipment,
decided_by text not null, -- system | cbp_request | consolidation
forced_formal boolean not null default false,
parent_entry text, -- set when shipments merge onto one entry
decided_at timestamptz not null
);
The column worth adding before you need it is parent_entry. Once shipments merge, the value band that made informal entry available stops describing the filing, and a report that still shows two eligible entries will disagree with the one that was made.
The declaration is an artifact, store it
Where a center director authorizes it, 143.23 permits an informal entry on a commercial invoice carrying a signed declaration, and the wording is fixed. It covers accuracy to the signer's knowledge and belief, invoice quantities matching manifest quantities, and the absence of any other invoice received or known. That third clause is a claim about your own documents, so the row should record which document was signed and by whom, not merely that a filing happened. 143.27 wants the invoice for the transaction itself, and only falls back to an itemized statement of value when no invoice exists, which is a second artifact with a reason attached to it.
create table entry_document (
shipment_id text references inbound_shipment,
kind text not null check (kind in
('commercial_invoice','itemized_value_statement','declaration_signed')),
signed_by text,
reason_no_invoice text, -- why the statement replaced the invoice
stored_at timestamptz not null default now()
);
A power of attorney sits behind all of this. 141.31 lets the instrument be drawn for a single transaction or for the whole of a principal's customs work, and rejects one running to a minor, so scope and expiry are fields rather than a folder.
None of this is legal advice, and a filing decision belongs to whoever signs it. What a schema can do is stop hiding the three facts the rule keys off, which are value of the portion, landing, and role. FulfillNexa by SBT (fulfillnexa.com) runs inbound for sellers at three Chinese sites, the Suzhou floor measuring 13,000 square meters, Dongguan 8,000 and Shenzhen 3,000, and we are never the signer on an entry. The landed_at and the value we were told at the door are our rows, and they are the two fields most often missing when someone else has to explain a filing months later.
Top comments (0)