How to Write an RFP for Your Core Business System: A Requirements Guide That Works

A common scene in a failed core business system project: a thick document, hundreds of lines long, lands on a vendor's desk. It lists every feature anyone in the company ever wished for. It says nothing about why the company is replacing its system in the first place. The vendor either disappears, or returns a vague proposal that misses the point. Six months later, the project is over budget and under loved.

The document is the RFP, the request for proposal. And most of them fail not because they are wrong, but because they are written the wrong way around. This is a guide to writing one that actually works.

Start With the Why, Not the Wishlist

Before a single requirement goes on paper, answer one question in one sentence: what is broken right now that this project must fix? Month-end close takes two weeks. One person holds the whole system in his head. Consumption tax is a quarterly scramble. Pick the real pain, name it, and let it drive every later decision.

The biggest cause of failed requirements, in the experience of Japan's information-technology promotion body and the consultants who clean up afterward, is that the business purpose was never shared. Teams write wishlists instead of problems. A good RFP is built on a problem, not a fantasy feature list.

Who Must Be in the Room

A requirements document written by one person, in one department, will miss the company it is meant to serve. The people who feel the pain have to be the ones who describe it.

That means the accounting lead who closes the books, the warehouse or operations lead who counts the stock, the sales lead who chases orders, and someone with authority to decide. If management and the working teams are not in the same room when the requirements are set, the gaps show up later, expensive and late. A vendor cannot guess what your business needs. Your own people have to say it.

The RFP Sections That Actually Matter

You do not need a hundred sections. You need the right ones, written in business language a vendor can act on, and tied to the core business system you actually want to run. Cover at least these.

The company itself. Your legal entity details, corporate and tax registration numbers, the timezone your business runs in, your fiscal year-end, and your date and number formats. These sound trivial. They are not. A system that cannot hold your company's basic identity produces documents and reports that are wrong from the first page.

Accounting at the core. Insist that double-entry bookkeeping is the foundation, not an add-on. Consumption tax must run through separate output-tax and input-tax accounts at every rate, with each trading partner's qualified-invoice registration number stored on their record. If tax is handled as a hand-typed field, the invoice system becomes a permanent headache.

The operational backbone. Sales orders, purchasing, inventory with lot traceability, and the workflow that routes approvals to the right person. State what must connect, so a sale flows from order to invoice to journal entry without a human re-keying it.

Access and language. Who needs to reach the system, from where, and in which language. If your team works across Japanese and English, say so up front, and ask whether the system is authored natively in both, not translated on the surface.

Data and growth. How each company's data is isolated, how you back up, and how you would start small and expand. Ask the vendor to show you a parallel run, old and new side by side, before you commit.

The Depth Test: Not Too Thick, Not Too Thin

An RFP can fail by being too long or too short. A document of hundreds of lines, every conceivable feature demanded, makes serious vendors walk away. A thin one, a few vague paragraphs, returns proposals so generic they are useless.

Aim for depth on what matters and brevity on what does not. For each real pain point, write enough that a vendor understands the business problem and can respond with a concrete approach. For everything else, a line is enough. The test is whether a vendor who has never seen your company could read it and understand what success looks like.

A Real-World Scenario

Consider a trading company in Yokohama with about 50 staff. Its first attempt at an RFP ran to over three hundred lines, assembled by forwarding every department's wish-list into one file. Two vendors declined to bid. The third returned a proposal for a system that would have cost more than the company's annual profit and still would not have fixed the month-end close.

The company rewrote it. They started with the why: the close took 12 days and consumption tax was a fire drill every quarter. They brought accounting, inventory, and sales into the same room. They cut the document to under 40 lines, each tied to a real problem, and they specified the few things that mattered: accounting as the core, separate consumption-tax accounts, lot traceability, approval workflows, and native Japanese and English.

The new RFP returned three focused proposals, each readable in an afternoon. The company chose a cloud core business system that met every line of the short list: accounting as the core, separate consumption-tax accounts, lot traceability, approval workflows, and native Japanese and English. It ran old and new in parallel for two months, migrating customers, vendors, products, and opening balances, and only cut over when the finance lead signed off that the new figures matched the old. Month-end close fell from 12 days to two. The document that worked was the short one built on a real problem, not the long one built on a wishlist.

Common RFP Mistakes That Sink Projects

Demanding every feature anyone ever wanted, instead of the few that fix the real pain. Letting one department write the requirements alone. Writing in technical terms the business cannot verify later. Forgetting consumption tax and the invoice system until the audit looms. Skipping the parallel-run requirement, then being forced into a blind cut-over. Choosing the cheapest proposal without reading what it actually delivers.

Is Your RFP Ready?

It names the single biggest pain this project must fix. It was written with accounting, operations, and sales in the room. It requires accounting at the core and consumption tax structured, not hand-typed. It specifies a parallel run before commitment. A vendor who has never met you could read it and know what success looks like.

Frequently Asked Questions

How long should an ERP RFP be?

Long enough to describe each real problem in business terms, and no longer. For most small and mid-sized companies, that is a few dozen lines, not a few hundred. A vendor should be able to read it in an afternoon and respond with a concrete approach, not a generic brochure. Depth on the pains that matter beats breadth on features that do not.

Do we need a consultant to write it?

Not always. You need the people who feel the pain in the room, a clear statement of the problem, and the discipline to cut the wishlist. A consultant can help structure it, but no consultant can substitute for your own team naming what is actually broken.

What is the one thing most RFPs forget?

The parallel run. Companies specify features and forget to require old and new systems running side by side until the team trusts the new figures. Without it, you commit blind. With it, you verify before you risk anything. For the broader framework, see our cloud ERP selection guide.

Key Takeaway: A good RFP is built on a named problem, written with the people who feel it, deep on what matters and brief on what does not, and it always requires a parallel run before you commit.

Ready to Test Your Requirements on a Real System?

You do not need a finished RFP to start learning what is possible. Start free with up to 2 users and no credit card on Kikan System, bring your real month-end headache, and let the system show you which of your requirements it already meets.

→ Start free