Google Shopping Feed for Business Central

Key Features

Table and page extensions on `Item`, `Item Variant` and `Item Category` adding `google_product_category`, `product_type`, GTIN, MPN, brand, condition, shipping label and custom labels 0-4, editable directly on the Item Card

Category-level default mapping with per-item override, so a large catalog is mapped by rule instead of SKU by SKU

Price resolution from the price list lines applicable to a nominated customer price group, including sale price with a correct `sale_price_effective_date` window from active campaign lines

Availability derived from Business Central inventory — in stock / out of stock / backorder against configurable thresholds, optionally filtered by location or warehouse

RSS 2.0 XML and TSV feed output, plus optional direct submission through the Google Content API for Shopping with credentials held in isolated storage

Per-country feed profiles carrying their own target country, language, currency, tax and shipping settings, each generating an independent feed from one catalog

`Job Queue Entry` scheduling with a full rebuild job and an incremental delta job that re-emits only items changed since the last successful run

Event subscribers on item, price list line and item ledger entry modifications that mark SKUs dirty for the next delta run

`Feed Item Log` recording, per SKU and per run, whether an offer was included, excluded or suppressed, with a specific reason code

Pre-flight validation that flags or blocks offers failing Google requirements — missing GTIN, blank brand, zero price, no image, blocked item, unmapped category — before submission

Disapproval diagnostics view pulling `productstatuses` back from Merchant Center so Google's rejection reasons appear against the Business Central item

Image handling from Business Central media fields or an external image URL field, with additional-image support and a fallback order you define

API pages (REST API v2.0 / OData v4) exposing feed runs and per-item feed status for Power BI, Power Automate or Dataverse consumption

Dedicated permission sets separating feed configuration, feed run execution and read-only diagnostics from general item maintenance

Exclusion rules by item category, item attribute, blocked status, price threshold or custom filter, so clearance and trade-only lines never reach the feed

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Merchants running Google Shopping ads usually maintain their feed somewhere other than Business Central: a spreadsheet a marketing assistant updates on Fridays, a webshop plugin that only knows what the storefront knows, or a paid feed tool that re-scrapes the website and inherits every error already on it. Meanwhile the real numbers — the price on the applicable price list line, the quantity on the item's inventory, the item's blocked flag, the variant that shipped this morning — live in Business Central. The gap shows up as disapproved offers, Price mismatch and Availability mismatch warnings in Merchant Center, and ad spend on items you cannot ship. Business Central out of the box has no concept of a Google product category, a GTIN validation rule, a brand/mpn attribute set, or a feed endpoint, so there is nothing native to configure.

We build a per-tenant AL extension (or an AppSource-track app, if you prefer that packaging) that treats the feed as a first-class Business Central object. A Google Feed Setup page holds Merchant Center account IDs, target countries, languages and currencies. Table extensions on Item, Item Variant and Item Category add the Google-specific fields Business Central lacks — google_product_category, product_type, GTIN, MPN, brand, condition, shipping label, custom labels 0-4 and an exclusion flag — surfaced on page extensions of the Item Card and Item List so your product team edits them where they already work. Mapping tables let you set defaults at item-category level and override per item, so a 40,000-SKU catalog is mapped by rule rather than SKU by SKU.

A feed generation codeunit walks the resolved item set and emits offers according to your rules: price from the price list line applicable to a nominated customer price group, availability from in stock / out of stock / backorder thresholds you define against Item Ledger Entry or an availability-by-location calculation, sale price from active campaign lines with a correct sale_price_effective_date window, and images from Business Central media fields or an external CDN URL field. Output is produced as RSS 2.0 / Google XML plus a supplementary TSV, published either at a content-delivery URL served from an API page or pushed to your destination — SFTP, Azure Blob, or direct upload through the Content API for Shopping using credentials held in isolated storage. Per-country feed profiles regenerate the same catalog under different currency, language, shipping and tax rules so feed_ES, feed_DE and feed_AE stay consistent instead of drifting apart. Everything runs on Job Queue Entry records — a full nightly rebuild plus an incremental delta job driven by event subscribers on item, price list line and inventory modifications, so only touched SKUs are re-emitted between rebuilds.

The diagnostics side is where feeds usually fail quietly. We build a Feed Item Log showing, per SKU and per run, whether an offer was included, excluded or suppressed and why — missing GTIN, blank brand, no image, zero price, item blocked, category unmapped. Where the Content API is connected, we pull productstatuses back into Business Central so Google's own disapproval reasons appear next to the item record, filterable and exportable, instead of living only in the Merchant Center UI. A pre-flight validation run surfaces the problems before Google sees them. Optional Power BI, Power Automate or Dataverse consumption through API pages (REST API v2.0 / OData v4) lets marketing report on feed health beside spend, and dedicated permission sets keep feed configuration separate from routine item maintenance.

This is build-to-order work, not a download. You request a quotation, we run a scoping call covering your catalog structure, price list setup, target countries and preferred delivery method, then quote a fixed scope. Typical delivery is 2-4 weeks from confirmed scope. We build against your Business Central version and deployment type (SaaS online or on-premises, current supported release waves), test on your sandbox with your real item data, run UAT with you, and install into production with a documented rollback path. You receive the AL source and the git repository, so the extension remains yours to maintain or hand to another partner.

What you get

Installable AL extension source and a signed `.app` package built for your exact Business Central version and deployment type (SaaS online or on-premises)

Installation and configuration on your sandbox and production environments, including job queue setup and Merchant Center / Content API credential wiring

Technical documentation — object ID ranges, table and page extension reference, codeunit and event subscriber map, API page endpoints, permission sets

User guide covering item mapping, feed profiles, running and scheduling feeds and reading the diagnostics log, plus a live training session for your product and marketing team

UAT on your sandbox with your real catalog data, an agreed acceptance checklist, and a documented rollback plan before the production install

Post-go-live support window for defect fixes and configuration adjustments, agreed in the quotation

Git repository handover with full commit history, so your team or another partner can maintain the extension

Feed validation report from the first production run, listing every excluded SKU with its reason so your team has a concrete data work list

Who this is for

E-commerce or Performance Marketing Manager

Runs Shopping and Performance Max campaigns and is judged on ROAS. Needs the feed to reflect real prices and real stock so budget is not spent on disapproved or unshippable offers, and needs to see why a SKU is missing without raising a ticket.

Business Central Functional Consultant or Partner

Owns the customer's Business Central estate and does not want a bolt-on tool holding a second copy of the catalog. Wants a proper AL extension with clean object ranges, permission sets and upgrade codeunits that survives release-wave updates.

Product / Catalog Data Manager

Maintains items, variants, categories and images. Needs Google attributes on the Item Card alongside everything else, with category-level defaults so a new SKU inherits correct mapping rather than needing separate feed work.

IT Manager or Systems Owner

Accountable for what connects to Business Central. Wants credentials in isolated storage rather than a spreadsheet, scheduled work on the job queue rather than an external scraper, and the source code in a repository the business controls.

How Google Shopping Feed for Business Central Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Source of truth for price and stock	Reads Business Central price lists and inventory directly, no second catalog	Same if built correctly — depends on your team's Business Central depth	Often reads the webshop, inheriting whatever is already wrong there	No feed concept exists; the data stays inside Business Central
Google-specific item attributes	Table and page extensions put them on the Item Card with category defaults	Built to spec, but the attribute set and defaulting logic are designed from scratch	Usually mapped in the vendor's own UI, away from the item record	No `google_product_category`, GTIN validation, brand or custom label fields
Multi-country feeds	Feed profiles per country with own currency, language, tax and shipping	Achievable, but commonly scoped as a later phase and delayed	Often licensed per feed, so cost rises with every new market	Not available
Freshness and scheduling	Job queue full rebuild plus event-driven incremental delta runs	Depends whether change tracking was budgeted or a nightly full run was accepted	Fixed vendor schedule, typically daily, rarely event-driven	Manual export at whatever cadence someone remembers
Disapproval visibility	Merchant Center statuses pulled back per item, filterable inside Business Central	Rarely built — projects usually stop once the feed generates	Dashboards in the vendor portal, disconnected from the item record	None; problems visible only in Merchant Center
Ownership of the code	Full AL source and git repository handed over to you	You own it, and you own every future fix and release-wave update	Closed source; the subscription runs for as long as you need the feed	Nothing to own
Cost shape	One-time build against fixed scope, optional ongoing support agreement	Internal developer time, usually underestimated and open-ended	Recurring subscription, often tiered by SKU count or feed count	No licence cost, absorbed as permanent manual staff effort
Time to a working feed	2-4 weeks from confirmed scope, tested on your sandbox with real data	Months, competing with the rest of your Business Central backlog	Fast to install, then weeks of mapping and reconciling data mismatches	Immediate spreadsheet export, then permanent manual maintenance

Frequently Asked Questions about Google Shopping Feed for Business Central

Is this a Microsoft AppSource app I can install today?

No. This is build-to-order. ECOSIRE builds the extension for your Business Central version, catalog structure and target markets after a scoping call. If you would rather have it packaged as an AppSource-track app than a per-tenant extension, say so during scoping and we build it that way.

How long does delivery take?

Typical delivery is 2-4 weeks from confirmed scope. The scoping call establishes your catalog size, price list setup, number of country feeds and delivery method; we then quote a fixed scope and timeline. Very large catalogs, unusual pricing structures or multiple Merchant Center accounts can extend that, and we tell you before you commit.

Does it work on Business Central SaaS and on-premises?

Yes. We build against your deployment type and current supported release waves. SaaS online tenants get a per-tenant or AppSource-track extension with no dependency on base app changes; on-premises builds target your specific version. If you are mid-upgrade, give us the target version and we build for that.

What happens with support and Business Central updates?

The quotation includes a post-go-live support window for defect fixes and configuration adjustments. Beyond that, ongoing support and release-wave compatibility work are available as a separate agreement. Because you receive the full AL source and git repository, you are never locked in — your own team or another partner can maintain it.

Do I need the Google Content API, or can it just publish a feed file?

Either. The simplest setup publishes XML or TSV at a URL Merchant Center fetches on a schedule, or drops it to SFTP or Azure Blob. Direct Content API submission is optional and adds near-real-time updates plus the disapproval diagnostics pull-back. We recommend it where pricing or stock is volatile, but it is not required.

How does it handle multiple countries and currencies?

Each feed profile carries its own target country, language, currency, price list or customer price group, tax and shipping configuration. One catalog produces independent feeds per market from the same source data, so a price change in Business Central propagates to every market feed on the next run instead of being re-keyed.

What if our item data is incomplete — missing GTINs, no brands?

That is normal and the extension is designed for it. Pre-flight validation and the Feed Item Log tell you exactly which SKUs fail and on which attribute, giving your team a work list instead of a Merchant Center error count. The first production run ships with a validation report doing exactly that. Incomplete source data will still limit feed coverage — we surface the gaps, we cannot invent the values.