SEE IT IN ACTION
Watch how the automation works
SEE IT IN ACTION
Most gaps between a dealership's dealer management system and its ERP are filled by a person, not an interface. At Sundaram Motors, keeping Nextflo ERP in step with the Mercedes-Benz Skyline Portal meant one employee repeating four steps every working morning:
What it cost. Around four hours of hands-on work a day, human error introduced during cleaning, and single-employee dependency — if that person was on leave, the integration simply didn't run, and finance was blind until they returned.
Dealer management system automation is the use of RPA or API integration to remove manual work between a dealership's DMS or OEM portal and its ERP, accounting and reporting systems — extracting reports, applying business rules and posting the result, without a person in the loop.
In practice, this covers everything from a single scheduled workflow that cleans and uploads GST invoice data, through to a full automotive dealer management system stack that also reconciles two finance systems and feeds a live management dashboard — which is what runs today at Sundaram Motors and VST Motors.
A scheduled Robot Framework job logs into the Skyline Portal, downloads the day's GST invoice and purchase-order reports, and hands them to a Python layer that runs two workflows: automated invoice processing that removes cancelled, test and non-applicable entries and backfills missing GST state codes, and a vendor purchase-order backfill that applies the dealership's default supplier wherever the export leaves a vendor field blank. The processed file is posted straight to the Nextflo API, and an acknowledgement email confirms the run.
Reconciliation used to mean pulling data from two systems, comparing it manually, and writing up the differences. The bot now downloads from both Skyline and NetSuite, normalises the two datasets in Python, reconciles them automatically, and emails the results to the finance team on a schedule. What was a periodic scramble is now a routine report.
Business managers and the Managing Director previously had to ask an employee, or pull and analyse Skyline reports themselves, to see how the business was tracking. The bot now extracts and consolidates that data on a schedule and feeds a live dashboard, so management gets the picture without going through anyone.
VST Motors needed a different output shape. The daily reports had to be split into Master Data and Detailed Data, enriched with SLC codes, and handled differently by invoice category — warranty, extended-service package and insurance invoices each follow their own rules. The bot downloads from Skyline, applies the full transformation in Python, and inserts the results directly into the Master and Detailed database tables, then emails an acknowledgement.
Same portal, different destination. Sundaram Motors posts to an API; VST Motors writes to database tables. This dealer management system integration pattern shares its extraction and processing layers across both sites — only the integration layer and business rules differ per dealership. That is what makes the next deployment fast.
The highest-volume, most measurable of the four automations is the GST RPA invoice automation at Sundaram Motors, so it's worth showing exactly what a morning's run looks like.
| Invoice / PO No. | State code | Vendor | Bot action |
|---|---|---|---|
| INV-2261140 | 33 | SUP-0418 | Passes unchanged |
| TEST-000119 | 33 | SUP-0418 | Test entry removed |
| INV-2261141 | 33 ← backfilled | SUP-0207 | State code completed from approved mapping |
| INV-2260084 | 33 | SUP-0112 | Cancelled removed |
| PO-884013 | 33 | SUP-0001 ← default | Vendor backfilled from default supplier |
Illustrative rows built from client-approved rules. Real values are client-confidential.
Both workflows run on a schedule on an Ubuntu server using a headless browser. Every business rule sits in configuration, not code — which is exactly what made the same automated invoice processing software reusable, not just at a second workflow, but at a second dealership.
Any error at any stage triggers an email on the same run, so failures surface in minutes instead of at month-end. Each dealership runs its own pipeline independently, with separate credentials, folders and alert recipients.
The Sundaram Motors build established the automation logic. VST Motors went live without a rebuild — the same dealer management system integration approach, pointed at a different Skyline account with its own rules.
| Client | Scope | Build required | Status |
|---|---|---|---|
| Sundaram Motors | GST invoice automation, vendor backfill, NetSuite reconciliation, dashboard | Full build | In production |
| VST Motors | Database integration — Master & Detailed tables | Configuration and mapping reuse | In production |
Why this matters for the next dealership: replicability is no longer a promise. Invoice number patterns, default state codes, default suppliers and run schedules are all configuration values. Nothing in the core automation logic had to change between Sundaram Motors and VST Motors.
| Before | After | Benefit |
|---|---|---|
| ~4 hours of manual work daily | Under 2 minutes, unattended | ~1,250 hours a year, per dealership |
| T+1 data, 24-hour lag | Same-day, T+0 | Real-time financial visibility |
| Human error in cleaning | Rule-based logic | Consistent data quality |
| Manual reconciliation across systems | Automated, emailed on schedule | Differences surface early, not at close |
| Management asked staff for numbers | Dashboard, always current | Decisions without a data request queue |
| A full FTE tied to the task | Staff redeployed | Cost saved, better work done |
| One employee held the process | Runs regardless of who is in | Operational continuity through leave and turnover |
| No failure visibility | Instant email alert on failure | Problems surface in minutes, not month-end |
The value in this automotive dealer software build sits in the business rules and alerting, not the framework choice — a maintainable, open stack is what keeps a bot alive three years after handover.
Sundaram Motors and VST Motors, both Mercedes-Benz dealerships. Sundaram Motors runs three automations — GST invoice automation, NetSuite reconciliation and a management dashboard. VST Motors runs a database integration automation. All four are in production.
It is the use of RPA or API integration to remove manual work between a dealership's DMS or OEM portal and its ERP, accounting and reporting systems — extracting reports, applying business rules and posting the result, without a person in the loop.
The manual GST invoice routine took around four hours a working day — about 104 hours a month, close to 1,250 hours a year per dealership. Across both live deployments that is roughly 2,500 hours a year, completed instead in under two minutes.
Yes. A scheduled Robot Framework job logs in through a headless browser, navigates to the required reports and downloads them, then hands the files to a Python layer for transformation. This runs daily at both Sundaram Motors and VST Motors today.
Whether RPA can be used on an OEM dealer portal depends on the portal owner's terms, agreement and authorisation. Dealerships should confirm that automated access is permitted before deploying a bot. In this project, the automation operates with the dealership's authorised access and follows the agreed process.
A scheduled bot downloads the invoice and purchase-order export from the source portal, then a Python layer removes cancelled, test and non-applicable entries, backfills mandatory GST state-code and vendor fields from an approved mapping, and posts the cleaned file to the ERP — the same automated invoice processing pattern running at Sundaram Motors and VST Motors.
It depends on scope. A single scheduled workflow such as GST invoice automation is a smaller build than four integrated automations spanning reconciliation, a dashboard and database integration. A configuration-only deployment to an additional dealership, reusing existing logic, costs meaningfully less than the first build. Contact Gramosoft for a scoped quote against your specific portal and target system.
A dealer management system (DMS) is the OEM or dealership platform running day-to-day operations — sales, service, parts and invoicing — such as the Mercedes-Benz Skyline Portal. An ERP such as Nextflo or NetSuite handles company-wide finance, accounting and inventory. Dealer management system automation is what keeps the two in step without manual re-entry.
A first build covering extraction, cleansing and ERP integration typically takes several weeks, depending on how many business rules and target systems are involved. A second deployment at another dealership, reusing existing automation logic with only configuration changes, goes live considerably faster — closer to days than weeks, as it did at VST Motors.
T+1 means data becomes usable one business day after it is created — the standard lag of a manual, next-morning process. T+0 means the same data is available the same day it is generated. Gramosoft's automation moved both Sundaram Motors and VST Motors from T+1 to T+0 by removing the manual step in between.
There is no single best tool — the right choice depends on the target portal and integration. Gramosoft uses Robot Framework for browser orchestration and scheduling, paired with Python for data transformation, because both are open-source, maintainable RPA software and don't lock a dealership into one vendor's licensing model.
Yes. At Sundaram Motors the bot pulls from both the Skyline Portal and NetSuite, normalises both datasets in Python, reconciles them, and emails the result to the finance team on a schedule — turning a manual month-end task into a routine report.
Every workflow is built to fail loudly rather than silently. If a step errors — a changed selector, a missing field, an unreachable portal — the automation stops and sends an immediate email alert to the operations team, rather than continuing on bad data or failing without anyone noticing.
The automation fails loudly rather than silently and emails the operations team on the same run. Selectors and rules sit in configuration, so most portal changes are a configuration update rather than a redevelopment — and the fix applies across every dealership running the same pattern.
