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 Merchant API 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 Merchant API is connected, we pull productStatus 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 one working week 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.