Back to Blog
Hiring Guide|12 min read|

The Job Requisition FormWhere every good hire actually starts

Long before a job goes live, someone has to decide the role should exist, prove it is funded, and get the right people to sign off. That request is the job requisition form. Get it right and hiring moves. Get it wrong and your best candidate accepts another offer while your req sits in an inbox.

The six fields every requisition form actually needs

Job title & level

Exact title, seniority, internal band

Department & manager

Where it reports, who owns it

Reason for hire

New role or backfill, and why now

Employment type

Full-time, part-time, contract

Salary range & budget

Band, plus approved cost center

Approval chain

Who signs off, in what order

Most hiring teams obsess over the job posting and treat the requisition as annoying paperwork. That is backwards. The posting is marketing. The requisition is the decision. If the decision is sloppy, everything downstream inherits the mess: unclear scope, budget fights halfway through the process, and hiring managers who cannot explain what they are actually looking for.

I have watched growth-stage teams lose two weeks per role to nothing but req approval limbo. Not sourcing. Not interviews. Just waiting for someone to confirm the money exists. A good requisition form kills that delay by forcing the hard questions up front, which is also the fastest way to reduce time to hire before you touch a single candidate.

This guide covers what belongs on the form, why each field earns its place, how the approval chain should work, and a template you can copy today. It pairs naturally with building a hiring plan and writing the job description that follows. For the broader HR definition, the AIHR guide to requisitions is a solid reference, and SHRM's forms library shows how formal HR teams structure the paperwork.

What a job requisition form actually is

A job requisition form is the internal request a manager files to open a role. It is where a hire gets defined, priced, and approved before anyone outside the company hears about it. The form answers three questions in order: what is the job, what does it cost, and who says yes.

People confuse it with the job description and the job posting all the time. They are different objects with different jobs. The requisition is the business case. The job description is the role definition. The posting is the ad. You need the first before you write the second, and the second before you publish the third.

In a real applicant tracking system, the requisition is also the parent record everything hangs off. Every application, interview, and offer for that role traces back to a single req ID. That is how finance reconciles headcount against plan and how you avoid two managers quietly hiring for the same slot.

Requisition vs job posting: the difference that trips people up

Here is the cleanest way to hold it in your head. A requisition is internal and about approval. A posting is external and about attraction. The requisition asks your own leadership for permission and money. The posting asks candidates to apply.

The relationship is not always one to one. A single requisition might have three openings for the same role, which then becomes one job posting that hires three people. Or one team opens two separate reqs for a junior and a senior version of the same function, each with its own budget line. The req is the unit of budget and approval. The posting is the unit of advertising.

This matters for reporting. When you measure time to fill, the clock usually starts when the requisition is approved, not when the posting goes live. If your reqs sit unapproved for ten days, that delay is invisible unless you track from the requisition itself.

The anatomy

Every field a job requisition form needs

You can bloat a requisition into a 30-field monster that nobody fills out honestly. Do not. A tight form with the right fields gets completed properly, which beats a long form full of "TBD." Here is the set that earns its keep.

Job title, level, and internal band

Not just "Engineer." Senior Backend Engineer, IC3, band E4. The level drives the salary range, the interview loop, and the seniority of who reviews the req. Ambiguity here creates arguments later about whether the person you hired matches the role you approved.

Department, manager, and reporting line

Who owns the role, which team it sits in, and who it reports to. This tells finance which cost center absorbs the salary and tells the approver whether this hire fits the org design or quietly reshapes it.

Reason for the hire

New role or backfill, and why now. "Backfill for a departed senior AE" is a fast yes. "We are growing" is a slow maybe. A specific reason connects the hire to a business outcome, which is exactly what an approver needs to sign quickly and defend later.

Employment type and location

Full-time, part-time, contract, or temp-to-perm, plus remote, hybrid, or onsite and the legal work location. This affects benefits load, tax, and which employment laws apply, which means it changes the true cost of the hire.

Salary range and budget line

A real range, not "competitive," plus the approved cost center or budget line. With pay transparency laws spreading across states, the range on the req usually becomes the range on the posting. Deciding it here forces an honest conversation before a candidate ever asks.

Must-have requirements and target start date

The three to five non-negotiables that separate a qualified applicant from a fantasy one, plus when you need the person in the seat. A tight requirement list keeps the pipeline clean and makes resume screening far faster.

Approval chain and final decision owner

Who signs off, in what order, and who makes the final hiring call. Naming this on the form is the single most valuable field on it. Most stalled reqs die because nobody knew whose desk they were sitting on.

The approval chain, and why it stalls

The approval chain is where good requisitions go to die. Not because anyone objects, but because the form lands in a queue with no owner and no deadline. Fix that with two rules: keep the chain short, and give every step a service level.

A clean approval chain moves in one direction, not in circles

Hiring manager

Submits the req

Department head

Confirms need

Finance

Approves budget

HR / TA

Opens the role

Four steps is plenty for most companies: hiring manager submits, department head confirms the need, finance approves the budget, and HR or talent acquisition opens the role. If your chain has seven approvers, at least three of them are rubber-stamping and adding days for nothing.

Then attach a clock. Each approver gets 48 hours. If they miss it, the req escalates automatically. That feels like red tape but does the reverse. A visible deadline turns "I'll look at it later" into "I'll look at it now," which is the whole game when a strong candidate is deciding between you and someone faster.

Write it like this

What a good requisition looks like next to a bad one

The difference between a req that gets approved in a day and one that generates a thread of follow-up questions is almost always specificity. Same fields, different answers.

The same form, filled two ways. One gets approved in a day. One gets three follow-up emails.

Vague req

Reason: "We need more help."

Budget: "TBD, ask finance."

Requirements: "Rockstar with experience."

Approver: left blank.

Approval-ready req

Reason: Backfill for a senior AE who left in June; pipeline coverage dropped 30 percent.

Budget: $95k-$115k base, cost center MKT-04, approved in Q3 plan.

Requirements: 4+ years B2B SaaS sales, closed $1M+ ARR, HubSpot fluent.

Approver: Priya (Dept Head), then Finance, then TA. Final call: hiring manager.

Stop losing days to req approval limbo

Prepzo turns the requisition into a live record with a built-in approval flow, budget fields, and a pipeline that opens the moment sign-off lands. No more chasing inboxes.

Try Prepzo free

Copy this

A free job requisition form template

Paste this into a shared doc, a form builder, or your ATS. It is deliberately short. If a field does not help someone decide or act, it does not belong on the form.

Requisition ID: [auto-generated]
Job title & level: e.g. Senior Backend Engineer, IC3
Department & reports to: e.g. Platform, reports to Eng Manager
Hiring manager: name and email
Reason for hire: new role or backfill, with the business reason
Employment type: full-time / part-time / contract
Location & work model: city, remote / hybrid / onsite
Number of openings: e.g. 1
Salary range: e.g. $130k-$160k base
Budget / cost center: approved line item
Target start date: e.g. within 8 weeks
Top 3-5 must-have requirements: the real filters
Interview loop owner: who runs the process
Final decision owner: who makes the call
Approval chain: e.g. Dept Head, Finance, TA

Once this is approved, it should flow straight into a live pipeline. That is the point of keeping the requisition inside your applicant tracking system rather than a spreadsheet: approval and hiring become one connected process instead of two disconnected steps.

Five mistakes that turn a requisition into a bottleneck

1. Leaving budget as "TBD." A req without a real number is a req that gets kicked back. Decide the range before you submit, even if it stings.

2. No named approver. "Send to leadership" is not a chain. Name the humans. Unowned reqs are the most common cause of avoidable delay.

3. Copy-pasting the last req. Roles drift. A backfill from last year may have a different scope now. Re-check the requirements and the reason every time.

4. Vague requirements. "Strong communicator, self-starter" filters nobody. List the three things that would actually disqualify a candidate, then let the rest be preferences.

5. Treating it as one-and-done. A requisition is a living record. If the budget changes or the role gets put on hold during a hiring freeze, the req should reflect it, not sit stale while recruiters keep sourcing.

Frequently Asked Questions

What is a job requisition form?

A job requisition form is the internal request a manager submits to get formal approval to hire for a role. It captures the job title, department, reason for the hire, headcount type, budget, and required approvals before a job is ever posted. Think of it as the paperwork that turns a hiring wish into a funded, approved opening.

What is the difference between a job requisition and a job posting?

A requisition is internal and comes first. It is how a role gets approved and funded inside the company. A job posting is external and comes second. It is the public advertisement candidates see and apply to. One requisition can generate one posting, and a single posting can be tied to a requisition with multiple openings.

Who approves a job requisition?

It varies by company size, but a typical chain is the hiring manager submits, the department head confirms the need, finance signs off on budget, and HR or talent acquisition validates the role details before opening it. Smaller teams often collapse this to a founder or one leader plus finance.

What should a job requisition form include?

At minimum: job title, department, hiring manager, reason for the hire (new or backfill), employment type, salary range and budget, target start date, key responsibilities, must-have requirements, and the approval chain. Adding the interview loop and the person who owns the final decision saves time later.

Do small companies need a job requisition process?

Yes, though it can be lightweight. Even a five-person startup benefits from writing down why a role exists, what it costs, and who approved it. It prevents duplicate hiring, keeps budget honest, and creates a clean paper trail. The mistake is skipping it entirely, not keeping it simple.

Resources & Further Reading

Related Guides

External Sources

Abhishek Singla

Abhishek Singla

Founder, Prepzo & Ziel Lab

RevOps and GTM leader turned founder, building the future of hiring and talent acquisition. 10 years of experience in revenue operations, go-to-market strategy, and recruitment technology. Based in Berlin, Germany.