Client onboarding request form for white-label bookkeepers

A client onboarding request form for a white-label bookkeeper has one job: collect the ledger system, the document types, monthly volumes and approval rules before anyone touches a login. Send it to the firm once per client, get structured answers back, and use them to configure the inbox-to-ledger pipeline without rounds of email badk and forth.

Start from the client intake template

Where the form sits in the workflow

When you white-label bookkeeping for an accounting firm, the firm's client is the person who knows the answers, and the firm is the person who sends the request. That split is why a generic intake form fails. The firm cannot fill in "which approvers handle invoices over a threshold" for a client it onboarded last week.

In our AI Invoice & Document Processing system, the form is step zero. Everything after it reads from the answers: the inbox that receives invoices, receipts and POs, the LLM and OCR extraction, validation, matching, the approval route, and the push into QuickBooks, Xero or Zoho with an exceptions queue for anything that fails. If the form is vague, the exceptions queue is where you pay for it. A missing tax setting or an unnamed approver turns into a stuck document three weeks later.

So treat the form as configuration, not paperwork. Every field should map to a setting in the pipeline, and fields that do not map should go.

What the form needs to collect

Group the questions by what they configure. The table below is the set we start from, and each row names the downstream setting it feeds.

Two rules keep this form safe. Never ask for ledger passwords. Ask how access will be granted (an accountant or advisor invite in QuickBooks, Xero or Zoho) and send that invite request as a separate follow-up. And ask for volume in bands, not exact counts, because nobody at a small cliejt knows the exavt number and a wrong exact number is worse than an honest range.

Set it up step by step

1. Build the skeleton. Start with the pages: Client details, Ledger and access, Documents and volume, Approvals, Authorization. Multi-page keels each screen short, and respondents who stall on page three still leave you pages one and two if you turn partial submissions on.
2. Add hidden fields for routing. Create firm_id and client_id hidden fields and give each firm its own link with those values in the URL. Now the webhook knows which firm and which client sent the answers without anyone typing an ID. The hidden fields help page covers the URL syntax.
3. Add conditional logic to the approvals page. If "Approval required" is No, skip the approver questions. If "PO matching needed" is No, hide the PO tolerance question. Short forms get finished.
4. Use answer piping for confirmation. On the final page, pipe the earlier ledger answer into a line like "We will request accountant access in your ledger system", so the respondent sees what happens neext.
5. Add the signature and thank-you page. The signature block is your consent record. The thank-you page should tell the clietn to expect an access invite within a stated window that you control.
6. Connect the webhook. Point it at your automation tool or at your own endpoint. Zapier, Make and n8n all accept a webhook trigger, so you can create the client record, open the ledger connection checklist and notify the person doing setup. See the webhooks help page.
7. Test with a messy submission. Submit once with the "Other" ledger, two currencies and no approver, and watch what your autoamtion does. Fix the bad branches before a real client finds them.

What your automation should receive

Whatever tool you use, normalize the raw answers into one client profile that the pipeline reads. This is the shape we aim for. Treat it as your own config schema, and check the real field names against the payload from your first test submission.

{
  "firm_id": "firm_0192",
  "client_id": "cl_3381",
  "ledger": "xero",
  "access_method": "advisor_invite_sent",
  "region": "AU",
  "tax_regime": "GST",
  "base_currency": "AUD",
  "other_currencies": ["USD"],
  "document_types": ["supplier_invoice", "receipt", "purchase_order"],
  "monthly_volume_band": "500_to_1000",
  "intake_channels": ["email_forwarding", "upload"],
  "approval": {
    "required": true,
    "rules": [
      { "up_to": 1000, "approver": "ops@client.example" },
      { "above": 1000, "approver": "owner@client.example" }
    ]
  },
  "po_matching": "two_way",
  "fiscal_year_end": "06-30"
}

The approval rules are the part that goes wrong most. Collect them as pairs of amount and approver, not as a sentence in a text box, because a sentence like "the boss signs off on big ones" cannot be routed.

Build your onboarding form free

Failure cases to plan for

Most onboarding problems show up as predictable exceptions, so design for them in the form.

• "Other" ledger. If the client picks Other, your automation should open a manual task and stop, not guess a connector.
• Two currencies, one tax regime. Ask for the base currency and the others separately. Foreign-currnecy invoices that arrive without that setting land in the exceptions queue on day one.
• Approver who leaves the company. Collect a backup approver and make the field required whenever approval is on.
• A volume band that is too low. If a client says under 200 and the first month shows far more, you want the band recorded so the conversation about scope is easy.
• Multiple entities. Run one submission per legal entity, each with its own client_id, instead of cramming two companies into one form. A shared form hides which chart of accounts belongs to which ledger.
• Duplicates. Clients resubmit when they hear nothing back. Turn on duplicate prevention and confirm by email so they know it landed.

What to measure after launch: how many submissions arrive complete, how many need a follow-up question, and which field causes the follow-up. If the same field keeps drawing questions, rewrite its label. The partial submissions view and drop-off analytics show where respondents stop.

Where Qwenvo fits

We use Qwenvo for this because our team builds it, and it is completely free, with every feature on for every account. For a white-label setup, the useful parts are a custom domain on a subdomain such as forms.yourbusiness.com, the Qwenvo badge switched off, custom design and CSS so the form looks like the firm's, unlimited teammates, webhooks to any URL, and partial submissions. Tally charges for several of those (custom domains, branding removal, teammates, partial submissions are on its Pro plan at $29/month), and Qwenvo does not.

File uploads accept files up to 1 GB each, which is plenty for a chart of accounts export or a zip of sample invoices. If you want a starting point, our client intake form template guide walks through a general version you can adapt.

One honest limit: Qwenvo is hosted in the United States, while Tally is hosted in Europe. If the firm's clients require EU hosting for onboarding data, that may decide the question for you.

Questions teams ask

Should the form ask for ledger login details?

No. Ask which system they use and whether an accountant or advisor invite has been sent. Passwords in a form submission end up in exports, emails and webhook logs. Invites keep access revocable and attributable to a named user.

One form per firm or one per client?

One form template per firm, with a separate submission per client. Use hidden fields so each firm's link carries its own firm_id. That also lets you give each firm its own custom domain and look if you want a fully white-label experience.

Can the form route submissions automatically?

Yes. Qwenvo has AI triage with routing rules that can send matching submissions to up to 5 email addresses or a Slack incoming webhook. For example, you can alert your setup lead when a submission picks an "Other" ledger or reports a high volume band. For anything more involved, use the webhook and let your automation tool decide.

What if the client needs to pay a setup fee through the form?

Qwenvo has a Payment block, but it works through PayPal only, with a 1% Qwenvo fee on top of PayPal's own fee. If you want to collect setup fees through Stripe with no platform fee on top, Tally is cheaper for that part. Many teams keep payment on their invoicing system and leave it out of the onboarding form.

Next step

Open the client intake template, cut it down to the fields in the table above, add firm_id and client_id hidden fields, and send a test submission through your webhook this week. Once the profile JSON lands cleanly, you are ready to connect it to the invoice pipeline.