Greenroom
Advanced

Form Validation and Error Handling

How Greenroom checks what you enter, and what to do when it flags something

Greenroom checks what you enter as you go, so problems get caught before they turn into a payroll or tax issue rather than after. Most of this is quiet: several fields format themselves as you type, and you'll only see a message when something genuinely needs fixing.

Required fields

Required fields are marked with a red asterisk (*) next to the label. On most forms you can't save until they're filled in.

Company setup's Business info is the exception, on purpose, so you can save as you go. It saves what you've entered, marks each missing field ("Business type is required"), and lists them under Complete these to finish business info. Whenever that summary isn't showing, a quieter line says what's left: Still needed to finish this step: followed by the fields (once Greenroom has approved your company, Still needed in Business info: in the Business info group of Settings → Company, and Still needed: in its Payroll and approvals group, which holds the expected payee count, the expected first payroll and the pay frequency). The stage isn't complete until every required field is filled: Legal company name, FEIN, Business address, Business type, Phone, Expected payee count, Expected first payroll, and Website, plus a pay frequency.

Fields that format themselves

Phone numbers, Social Security numbers, and EINs format themselves as you type — just type the digits and Greenroom adds the punctuation:

FieldType thisGreenroom shows
Phone2125550100(212) 555-0100
SSN123456789123-45-6789
EIN12345678912-3456789

You don't need to add dashes or parentheses yourself.

Phone numbers

A payee's phone has to be a real one: a US number needs ten digits, however you punctuate it — 2125550100, (212) 555-0100 and +1 212 555 0100 are all accepted, and the country code isn't counted as a digit. An international number (anything starting + other than +1) is stored exactly as you type it, needing at least seven digits and no more than forty characters. Leaving it blank is fine; phone is optional on a payee.

Your company's phone is stricter — it must be ten US digits — because our tax partner refuses to approve a payroll for a company without one.

Your company's website

Business info's Website is checked against what our tax partner accepts. example.com, www.example.com, and https://example.com/about are all fine, and a trailing slash is dropped for you. A page file name, a space, ?, #, or a port number is refused, and the save with it: "Enter the website as a plain address, like example.com or https://example.com/about. Leave out page file names such as /about.html, spaces, ?, #, a port number and a trailing dot."

SSNs and EINs are masked after saving

Once a tax ID is on file, Greenroom only ever displays the last four digits (for example, •••-••-6789). A teammate with Admin or Payroll can view a full EIN with an explicit action, and every view is logged. Approvers cannot reveal it. A full Social Security number can't be viewed on screen at all, by anyone: you can replace it, but not reveal it. The field's help says so: "Greenroom shows only the last four digits of an SSN." When one of the payee's unions requires full SSNs on its fund report, the help adds where the full number prints: "The full number prints only on the [union] fund report PDF for an approved payroll they were paid on, which a teammate with Payroll or Admin can generate from Reports. Greenroom staff never see it." A fund report CSV never carries a full SSN. See Fund reports for one union.

Dates

On a payee's record (the date of birth, the start date, and the dates on pay rates and adjustments) dates are picked from Greenroom's calendar, not typed, so there's no date format to get wrong. Click the field to open the calendar, or use the year box next to the month dropdown to jump straight to a specific year (handy for a date of birth decades back). Some other screens, the payee's own setup and the Reports date range among them, use your browser's built-in date field instead.

A pay rate or adjustment dated before the payee's start date gets a second look. Picking that date asks Use a date before the payee starts?, and the row keeps the earlier date only once you click Use earlier date. The confirmation belongs to that exact pair of dates: change the start date and the row shows Confirm earlier date until you confirm again. See Role & Pay for how rate dates work.

Date of birth

A date of birth is checked in three ways that block a save, with the same wording wherever it's collected — the manager's form and the payee's own setup flow:

ProblemMessage
Not a real dateEnter a valid date.
Before 1900Review the year — dates before 1900 aren't valid.
In the futureDate of birth can't be in the future.

On the payee's record there's a fourth check that warns without blocking: a date that makes the payee under 5 gets a hint ("That date of birth makes this payee under 5 — double-check the year. If it's right, no action needed.") rather than a rejection. Child performers are real, they carry Coogan trusts, and they have to get paid — so this can never be a block. It exists because a date a few weeks in the past passes every rule above and our tax partner stores it without complaint, which means nothing else in the system would ever mention it.

Email addresses

Email fields trim spaces at the beginning and end before checking the address. Spaces inside the address are still invalid. An optional email left blank, or containing only spaces, counts as empty; a required email still needs an address. If the format is wrong, you'll see "Enter a valid email" until it's fixed.

Dollar amounts

Amounts are entered as dollars and cents. If you type extra decimal places, Greenroom rounds to the nearest cent automatically rather than showing an error. Most amount fields won't accept a negative number — the exception is payroll correction entries, which use a negative amount on purpose to claw back an earlier overpayment.

Bank details

Routing and account numbers get the strictest checking in the product. When you enter bank details for direct deposit:

  • The routing number is checked against the standard ABA bank checksum. One that doesn't check out is rejected with an explanation, not silently accepted.
  • Both the routing number and account number must be typed a second time to confirm, and pasting into the confirmation field is blocked on purpose — retyping is what catches a transposed digit.

See Payment Details for the full setup process.

Illustrative — required, auto-formatted, and checksum-checked fields, from the Greenroom app

Where error messages appear

Most field-level errors show up as plain-language text directly under the field, in red. The payment editor is the exception: its messages, such as "The routing and account numbers must match their confirmations." when a confirmation is mistyped, appear in red above its Save payment plan button. On forms with several sections at once, like the New payee page and a payee's own record, trying to save also shows a summary near the top of the form listing every problem, not only the first; click one to jump to its field. It's headed Finish these to create the payee on the New payee page and Finish these to save. Your other changes are kept. on a payee's record, where the rest of your edits are kept while you fix them. Either way, each message names the specific thing to fix, and typically appears once you leave the field or try to save — not on every keystroke.

If something won't save

  • Look for a red asterisk (*) on any empty required field.
  • Read the message near the field or at the top of the form — it names the specific problem.
  • For bank details, make sure the original and "confirm" fields match exactly (retype rather than paste).
  • Still stuck? See Troubleshooting.

Next steps

See Document Validation for the employer I-9 attestation and the rules for uploaded files, Address Validation for how address entry works, or Troubleshooting for more help.

On this page