Technology15 min read•

Connecting a Manufacturer's Website to Your ERP: Quote Requests, Customer Portals and the Invoice Data Your Software Needs

How a manufacturer's website should connect to its ERP: structured quote forms, customer portals, clean master data and the invoice data e-invoicing needs.

#manufacturer website#ERP integration#customer portal#RFQ form#GST e-invoicing data

A manufacturer's website should connect to the company's ERP or accounting software in three practical ways: quote and enquiry forms that land in the sales system with clean product and customer data, a customer area that shows orders, dispatch and invoice status pulled from the ERP, and master data (customer details, GSTIN, HSN codes, units) that is captured correctly once so that the invoicing system, including any GST e-invoicing integration, does not reject documents later. This article is for Pune manufacturers and engineering firms who are planning or fixing the web side of that connection. It explains what the website should capture, how data should flow to and from the ERP, the integration options, how to test and secure the connection and what to ask a developer, with GST e-invoicing treated only as one of the data requirements the website and ERP must satisfy together, not as a tax-filing guide.

We have rewritten this article from an earlier version that focused on tax compliance. Compliance rules change often, so we keep tax specifics to a minimum and point you to the official portals and your chartered accountant. What a web developer can usefully tell you, and what this guide covers, is how to get data into and out of your systems without re-keying and errors.

The Problem: Three Systems That Do Not Talk to Each Other

In many small and mid-sized manufacturers the website, the ERP or accounting package and the dispatch process are three separate islands. A buyer fills in a contact form. A salesperson copies the details into a spreadsheet or the ERP. The order is keyed in again. The invoice is raised from the ERP, with the customer's GSTIN typed from a visiting card or a WhatsApp message. Each manual step adds delay and a chance of error, and errors in master data, such as a wrong GSTIN or a mistyped HSN code, surface later as rejected invoices, disputed bills or lost follow-ups.

The website is often the first place where customer data is entered. If it collects that data badly, every system downstream inherits the mistakes. If it collects it well, with validation, structure and consent, it becomes the cleanest source of customer information you have. That is the argument for treating the website as part of the integration plan and not as a brochure that happens to have a form.

Step One: Decide What the Website Should Do

Not every manufacturer needs a full customer portal. Decide the scope honestly.

  • Brochure with enquiry form. Product pages, specifications, certifications and a form. Integration need: send enquiries to a CRM or the sales inbox with structured fields.
  • Catalogue with request-for-quote. Customers select products and quantities and submit a request for quote (RFQ). Integration need: product codes in the website match ERP item codes so quotes can be prepared quickly.
  • Account and order status. Existing customers log in to see orders, dispatch and invoices. Integration need: read access to ERP data through an API or scheduled sync.
  • Online ordering for trade customers. Customers place orders against negotiated prices. Integration need: two-way sync of prices, stock and orders. See our guide to wholesale and B2B ordering with trade pricing for the e-commerce side.

Start with the simplest level that solves a real problem and add levels later. Our article on B2B manufacturer websites, RFQs and export enquiries covers the content and conversion side of the first two levels, which this article assumes.

Step Two: Capture Master Data Correctly at the Website

Customer details

For B2B enquiries and accounts, the website form or account registration should collect, in separate validated fields: legal business name, trade name if different, contact person, email, mobile number, billing address with state and PIN code, shipping address if different, and GSTIN if the customer is registered. A single "address" text box produces data that cannot be matched with the ERP.

Validate what can be validated without calling anyone. A GSTIN is a fifteen-character code with a defined structure: the first two digits are the state code, the next ten are the PAN, followed by an entity number, a fixed character and a check character. A form can check length, pattern and that the embedded PAN follows the expected format, and can flag mistakes immediately, such as the letter O typed for zero. Checking the pattern does not prove that the GSTIN is active or belongs to that company; for that you need to verify against the GST portal or a licensed verification service, which is best done in the ERP workflow with the customer's consent. The principle is to catch typing errors early and verify identity at the right point.

Collect only what you need at the enquiry stage. Asking an anonymous visitor for a GSTIN before they have even seen a price discourages enquiries. A sound pattern is to ask for it when a quotation becomes an order or when a trade account is opened.

Product and item codes

The website's product catalogue should use the same item codes, names and units of measure as the ERP, even if customer-facing names are friendlier. Keep an item code field, such as SKU or part number, in the website's product records, and make it the key for any sync. Decide where each attribute lives: description, specification sheets and photographs can be managed in the website's content system, while price, stock, HSN code and unit of measure should be mastered in the ERP. If the same fact is edited in two places, they will drift apart.

HSN codes, units and tax rates

For goods, each item needs a Harmonised System of Nomenclature (HSN) code and a unit of quantity in the form the tax system accepts, with tax rates held in the ERP. The website normally does not need to display the HSN code to a casual visitor, but a B2B catalogue can, and the code must be right wherever it appears. Keep these in the ERP as the source of truth and expose to the website only what customers need. Check current rates and classification with your tax adviser, because rates and rules change.

Consent and privacy

Contact details entered into a website form are personal data under India's Digital Personal Data Protection Act, 2023, which also applies to business contacts at the level of named individuals. Tell visitors what you will do with the data, collect it only for that purpose and store it securely. Our article on DPDP website compliance explains the website's obligations in plain terms.

Step Three: Choose How Data Flows

Option 1: Forms into a CRM, then to the ERP

The most common first step. The website form sends enquiries to a CRM through its API, tagged with the source page and product. Sales qualify the lead, and when it becomes an order the data is passed to the ERP, either by the CRM's integration or by a manual export in the early days. This keeps the website simple and puts the sales workflow in a tool built for it. Our guide to connecting website forms to a CRM explains how to avoid duplicates and lost leads, and our CRM development services are relevant if you need something tailored.

Option 2: Direct ERP integration through an API

Many ERPs, including cloud-based ones, provide REST APIs or similar interfaces for reading items, customers, orders and invoices. The website's back end calls the API to look up order status, create quotations or fetch prices. This allows a customer area with live data, but it depends on the ERP vendor's API quality, rate limits, authentication method and licensing terms. Some ERP vendors charge for API access or restrict it to specific plans. Ask before you design around it.

For popular desktop accounting packages that were not designed for web integration, a connector or middleware is often needed, because the software may not expose a modern interface. Treat these as higher-risk: they can be fragile, may depend on a specific version and may require a machine to be always on.

Option 3: Middleware or an integration platform

A middleware layer sits between systems and translates data. It is useful when you have several systems (website, CRM, ERP, warehouse software) and need one place to log and retry transfers. It adds cost and another component to maintain, so it pays off with volume and complexity, not for a single form.

Option 4: Scheduled file exchange

A simple, robust option for modest needs: the ERP exports a CSV or JSON file of items, prices and order statuses on a schedule, and the website imports it; orders from the website are exported as files for the ERP to import. It is unglamorous and it works, provided you validate files, log every import and alert when a file does not arrive. For many manufacturers, a nightly or hourly sync of product price and order status is enough.

How to choose

Weigh these factors: how current the data must be (live stock versus daily), the ERP's real capabilities, the volume of transactions, who will maintain the connection, and what happens when it fails. Start with the least complex option that meets the need, and design so you can replace it later: put the integration behind a clean boundary in your code so the website does not depend on the ERP's idiosyncrasies.

Where GST E-Invoicing Fits

GST e-invoicing is the process in which specified taxpayers have their B2B invoices registered on the government's Invoice Registration Portal (IRP), which validates them and returns an Invoice Reference Number and a QR code. Who must do this depends on the taxpayer's turnover, set by notification and changed over time, and the rules on reporting timelines have also been tightened. Confirm the current applicability, thresholds and time limits on the official GST e-invoice portal and with your chartered accountant; do not rely on a web article, including this one, for the rules.

For the web integration, the relevant points are about data and responsibility.

  • The ERP or billing software generates and reports the invoice, not the website. The website's role is to supply correct upstream data: legal name, GSTIN, addresses, items and quantities, and to display status downstream.
  • Rejections usually come from data problems. Typical causes include an invalid or mismatched GSTIN, incorrect state or PIN code, missing HSN codes and unit mismatches. Good master data capture at the website and in the ERP prevents most of them.
  • Do not store IRP credentials in the website. If the ERP or a licensed provider handles the connection, keep credentials there, under access control.
  • A customer portal can show the IRN or invoice PDF once the ERP has generated it, retrieving it through the ERP or the invoice store. Treat invoice files as confidential, accessible only to the right customer.
  • Do not let the website create or alter tax invoices on its own. Invoice numbering and tax computation belong in one controlled system.

Our separate guide on CRM and accounting software integration covers the CRM-to-accounts flow in more detail, and for online stores see GST-ready invoices and checkout fields on WooCommerce.

Building a Customer Area That Reads From the ERP

What to show

A useful customer area for a manufacturer typically shows: open quotations, orders and their status, dispatch details with a tracking or vehicle reference where relevant, invoices and credit notes available for download, and a statement or outstanding summary if you choose to share it. Start with order status and invoice downloads, which answer the most common calls to the accounts and dispatch teams.

Authentication and authorisation

Customer accounts should be tied to a company and to named users. A purchase manager and an accounts clerk at the same customer may need different views. Use strong authentication, such as email or phone verification with codes, and consider whether to support multi-user accounts per customer. Never let one customer see another's data: every ERP query must be filtered by the authenticated customer's identifier on the server side, not by an ID the browser sends. Our article on passkeys and authentication explains modern sign-in options.

Performance and fallbacks

ERPs can be slow. Cache data that does not need to be live, show "last updated" times and handle ERP downtime gracefully with a clear message, not a broken page. Do not let a slow ERP call block the whole page.

Security and Reliability

  • Least privilege. Give the integration an ERP user or API key that can read or write only what it needs, and rotate keys.
  • Secrets management. Keep keys in environment configuration, not in code or the browser.
  • Encryption. Use HTTPS for all calls, and protect stored files and backups. See security headers for the website side.
  • Logging and audit. Log every transfer with timestamp, record ID and result, without logging sensitive data in plain text.
  • Idempotency. Design order and quote submissions so that a retry does not create duplicates: use a unique reference and check before inserting.
  • Monitoring and alerts. Alert someone when a sync fails, a file does not arrive or the error rate rises. A silent integration failure is worse than a loud one.
  • Backups and rollback. Know how to restore both systems if an import corrupts data; see backups and disaster recovery.
  • Breach readiness. Know your obligations if customer data is exposed; our article on CERT-In breach reporting explains the website-side duties.

Implementation Plan

  1. Map the current flow. Write down every step from enquiry to payment, who does it, in which tool, and where data is re-keyed.
  2. Pick the first, narrowest integration. For most manufacturers, enquiry forms into a CRM or sales inbox with structured fields.
  3. Clean the master data. Fix item codes, units, customer duplicates and missing GSTINs in the ERP before connecting anything. Integration amplifies existing mess.
  4. Define the data contract. For each field: name, format, source of truth, validation, and who may change it.
  5. Build and test with sample data in a staging environment, including bad inputs, duplicate submissions and ERP downtime. See our staging and rollback guide.
  6. Pilot with a few customers and compare the website records with the ERP for a few weeks.
  7. Train users and name owners for failed syncs, master data changes and credentials.
  8. Review quarterly. Update mappings when the ERP, tax rules or product range change.

What to Ask a Developer

  • Which integration option do you recommend for our ERP, and why? What are its limits and costs?
  • What will be the source of truth for items, prices, stock and customers?
  • How will you validate GSTIN, PIN code and unit fields, and what happens when validation fails?
  • How are credentials stored, and who has access?
  • What happens if the ERP is offline, and how will we know a sync failed?
  • Who owns the integration code and documentation after handover? See our website handover checklist.
  • What will it cost to maintain, and what changes on the ERP side would break it?

We do not quote a price for this kind of work here, because it depends heavily on the ERP, the number of data flows and the quality of existing data. A scoped quotation after a short discovery session is the honest route.

Frequently Asked Questions

Does my manufacturing website need to connect to my ERP?

Not necessarily. A brochure site with a good enquiry form can be enough. Connection becomes worthwhile when staff re-key enquiries or orders, customers keep asking for order status or invoices, or master data errors cause rejected documents.

Can a website generate GST e-invoices?

Invoices are normally generated and reported from the ERP or billing software or through a licensed provider, because numbering, tax calculation and credentials need to be controlled in one place. The website should supply accurate data and display the result. Confirm current e-invoicing rules on the official GST portal and with your accountant.

What data should a B2B website form collect for invoicing later?

Legal business name, contact details, billing and shipping addresses with state and PIN code, and GSTIN for registered customers, ideally collected when an order or account is created rather than at first enquiry, and validated for format.

Can Tally or an older ERP connect to a website?

Often yes, through exports, connectors or middleware, but options depend on the version and vendor. Check what the ERP supports, plan for fragility and consider scheduled file exchange as a reliable starting point.

How do I stop customers seeing other customers' data in a portal?

Filter every data request on the server by the logged-in customer's identifier, never by a value sent from the browser, use named user accounts and test the permissions with deliberate attempts to access other records.

Where to Start

List the steps from enquiry to invoice in your own business and mark each place where someone re-types data. Fix the master data first, then connect the form to a CRM or sales inbox. Govindani Infotech, a web development and CRM company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009, builds manufacturer websites and the integrations behind them; see our website creation services and CRM development, then contact us or call 092019 58274.

Sources:

About the author: written by the Govindani Infotech web and CRM team in Pune.

Need Help With Your Digital Strategy?

Govindani Infotech helps Indian businesses and NGOs build websites, run ads, and grow online. Contact us for a free consultation.