Certified Payroll Compliance Guides
Demystifying cryptic government portal errors. Learn why they happen and how XMLExpress solves them automatically.
Value '...' is not facet-valid with respect to pattern '[0-9]{4}' for type 'Last4SSNType'.
The WH-347 portal requires Employee ID to be exactly 4 digits — typically the last four of the SSN. Full SSNs, employee codes like 'EMP-0421', or names in this field will trigger a rejection. This is one of the most common first-time submission errors for small contractors.
'...' is not a valid value for 'date'.
Government portals require Week Ending dates in YYYY-MM-DD (ISO 8601) format. If your payroll exports dates as MM/DD/YYYY, DD-MM-YYYY, or any other regional format, the XSD parser rejects the entire submission. This is the #1 cause of first-submission failure.
Invalid content was found starting with element 'ContractorName'.
ContractorName is the very first required element in every WH-347 XML report. If it's missing, misspelled, or placed after employee data, the portal rejects the file before reading any other field — even if the rest of your data is perfect.
Gross $... does not match expected $...
Government portals don't just accept your Gross Amount — they recalculate it from hours and rates using the formula: Gross = (ST Hours × Rate) + (OT Hours × Rate × 1.5). Even a $0.05 rounding difference triggers a Business Rule rejection, requiring a full resubmission.
Net $... should equal $... (Gross - Deductions)
The WH-347 portal enforces a strict equation on every employee: Net Wages = Gross Amount − Total Deductions. If the numbers don't balance by even a penny, the submission is flagged as a Business Rule violation. This is the #1 cause of rejection for mid-sized contractors.
Element 'RateFringe' is unexpected
The WH-347 schema requires elements in a strict order. RateFringe must appear immediately after RateStraightTime and before GrossAmount. If it's placed anywhere else — or duplicated — the portal rejects the file with this cryptic 'unexpected element' error.
Element '...' is unexpected
A field in your XML isn't recognized by the WH-347 schema. This usually means a typo in the element name, an extra field your system added, or the element exists in the wrong parent section. The portal won't accept any unrecognized tags.
Element '...': This element is not expected
The element name is valid, but it appears in the wrong position. The WH-347 schema requires a specific sequence — for example, all contractor fields must come before employee data, and pay fields must follow hours fields. A single misplaced element causes a full rejection.
Element '...' is missing
A required field is completely absent from your XML. The WH-347 schema lists specific mandatory elements — if any are missing, validation fails immediately. Common missing fields: WeekEnding, EmployeeName, GrossAmount.
Element '...' contains an invalid character
XML can only contain legal Unicode characters. Special characters like &, <, >, and control characters from copy-pasting will crash the XML parser before it even reads your data. Emojis and non-printable characters are also rejected.
Value '...' is not facet-valid with respect to pattern '[0-9]{4}' for type 'Last4SSNType'.
The Employee ID field must contain exactly 4 numeric digits. Full SSNs (9 digits), partial SSNs (1-3 digits), or alphanumeric employee codes all trigger this error. Leading zeros are often stripped by Excel, turning '0123' into '123'.
'...' is not a valid value for 'date'.
Every WeekEnding date must be in YYYY-MM-DD format. MM/DD/YYYY, DD/MM/YYYY, and other regional variants are rejected. A single row with a bad date format can delay payment on the entire project.
'...' is not a valid value for 'decimal'.
Numeric fields like pay rates and deductions must be plain decimal numbers. Currency symbols ($), commas (1,500), and percentage signs (7.65%) will trigger a 'not a valid decimal' error. This often happens when exporting from accounting software that formats numbers for display.
Value '...' is too short
The WH-347 schema enforces minimum lengths on text fields — for example, EmployeeName must be at least 10 characters. Short entries like 'J. Smith' or 'Bob' fail this check, even if they're valid employee identifiers in your system.
Value '...' is too long
Text fields in the WH-347 schema have maximum length limits. If a field exceeds the limit — like a full legal business name in a short field — the portal rejects it. This often happens when data spills over from adjacent columns during CSV export.
Value '...' is not in the allowed list of classifications.
Work classifications must match exact Davis-Bacon Act job titles — 'Carpenter', 'Electrician', 'Laborer', etc. Internal codes like 'LAB-03' or abbreviations like 'Carp.' are rejected. This causes frustrating back-and-forth when your payroll system uses different names.
Invalid content was found starting with element '...'.
The WH-347 schema enforces strict element ordering within each section. If Contractor fields are mixed with Employee fields, or if a required element is missing, the entire validation fails. This error can be hard to debug because the error message doesn't clearly say 'wrong order'.
Duplicate employee record detected.
Two or more rows in your payroll have the same Employee ID. This could mean a genuine SSN collision (rare), a copy-paste duplication, or an employee working under multiple classifications. Portals flag duplicates as potential data integrity issues.
Certification statement is missing or unsigned.
Every WH-347 certified payroll report must include a signed certification statement attesting to the accuracy of the data. If this statement is missing or unsigned, the portal treats the submission as incomplete — even if all payroll data is correct.
Value '...' is out of the allowed range.
Numeric fields have sensible ranges — negative hours, rates over $500/hr, or employees working 100 hours in a single day will be flagged as impossible values. These errors catch typos and data entry mistakes before they reach the payroll record.
LCPtracker rejected the submission.
LCPtracker, used by many government agencies, applies additional validation rules beyond the base WH-347 schema. A submission that passes basic XSD validation can still fail LCPtracker's proprietary checks — confusingly, without a specific error code.
AASHTOWare Project rejected the submission.
AASHTOWare Project, used by state DOTs for construction management, has its own XML schema requirements including specific namespace declarations. Submissions that pass basic WH-347 validation may fail AASHTOWare's namespace and format checks.
Content is not allowed in trailing section.
XML files must have exactly one root element. If there's text, whitespace, or extra XML after the closing tag of the main element, the parser rejects the file. This often happens when files are concatenated or edited manually.
Portal authentication failed.
The government portal (LCPtracker, AASHTOWare, etc.) rejected your login credentials or API token. This isn't a file format error — it's an access issue that prevents your submission from even being processed.
Unsupported file format.
The portal only accepts .csv or .xml files. Uploading .xlsx, .pdf, .txt, or any other format will be rejected before any validation begins. Contractors often export from Excel in the wrong format.
Rate conflict for classification '...'.
Davis-Bacon Act rules require that all employees with the same work classification on the same project receive the same prevailing wage rate. If one employee is paid differently than others in the same classification, the portal flags it as a potential violation.
Fringe benefit details are missing.
Under the Davis-Bacon Act, many work classifications require employers to pay a fringe benefit rate in addition to the base hourly wage. If fringe information is missing or the field is empty, the portal flags the submission as potentially non-compliant.
Project ID mismatch.
The project number or ID in your payroll doesn't match the registered project on the portal. This happens when using the wrong contract number, project code, or when data crosses between different public works projects.
Duplicate submission detected for project '...'.
The portal has detected that a certified payroll report for this project and week has already been submitted. Duplicate submissions are rejected to prevent data conflicts — even if the original submission had errors that you're trying to correct.
Field '...' is empty or null.
A required field contains an empty or null value. The WH-347 schema requires every mandatory element to have content — blank values cause an immediate validation failure. Common culprits: missing Employee Names, empty Week Ending dates, or blank Rate fields.
Stop battling errors manually
XMLExpress validates every file against the official schema — catching these errors before you ever click submit.
Start Your Free Conversion