A poultry business is measured in grams and days, not in monthly journals. Feed conversion ratio, daily mortality percentage, hen-day production, average egg weight, live weight gain and cost per dozen or per kilo decide whether a cycle made money — and every one of them is a function of a specific flock, in a specific house, on a specific day. Dynamics 365 Business Central handles the finance side of that business well: purchase orders for feed and day-old chicks, inventory valuation, sales invoices for eggs and live birds, dimensions, fixed assets for houses and equipment. What it does not have is a flock. There is no standard table that knows a batch was placed on a date at a given bird count, no place to post a mortality of 43 birds against it, and no way for Business Central to tell you that House 4's cycle closed at an FCR of 1.68 while House 2 closed at 1.91. So the flock lives in a spreadsheet, feed issues post as unspecific consumption against a generic item, and the profitability question gets answered weeks late by hand.

The usual workarounds each break somewhere. Using item tracking lot numbers as pseudo-flocks gives traceability but no daily production register and no bird-count arithmetic. Using a Job per cycle captures cost but forces every biological event through a job journal never designed for a mortality count or an egg grade. Using dimensions alone gives you a slice of the G/L and nothing operational — no opening bird balance, no closing balance, no reconciliation proving that placed minus mortality minus culls minus sales equals the birds actually in the house. None of these survives a bank review or an audit, because the numbers cannot be tied back to a posted document.

We build a dedicated AL extension that adds a poultry layer to Business Central and wires it into the standard posting engine rather than around it. New tables carry the Flock (house/location, breed, placement date, placed quantity, planned cycle length, target FCR) and the Flock Batch Ledger Entry, an append-only register recording every event that changes bird count or production under its own entry type — placement, transfer, mortality, cull, sale, weighing. Daily activity is captured on a Poultry Daily Log page: feed issued by item and quantity, mortality by cause code, water, temperature, medication and vaccination. Posting that log runs a codeunit that creates the item journal lines for feed consumption, writes the flock ledger entries and stamps the flock shortcut dimension, so the G/L slices by flock with no extra keying. Egg production posts by grade against a grading setup you define (Jumbo, XL, Large, Medium, Pullet, Cracks, Dirty), each grade mapped to its own item number, so one posting run both moves inventory and builds the production statistics. Table and page extensions add poultry fields and FactBoxes to Item, Location, Customer and Vendor; event subscribers on the item, sales and purchase posting codeunits keep the flock ledger consistent when users post from standard pages. A job queue entry runs the nightly rollup for FCR, cumulative and daily mortality percentage, hen-day and hen-housed production, average bird weight and cost per unit produced, and API pages (REST API v2.0 / OData v4) expose flocks, logs, production and cost so Power BI, Power Automate and Dataverse read live data instead of an export. Dedicated permission sets separate the supervisor who logs mortality from the accountant who closes the cycle.

Everything is shaped to your operation. A layer farm and a broiler grow-out farm need different cycle logic, different KPIs and different closing rules; a contract grower needs settlement against the integrator's terms, while an independent farm needs full cost absorption. That shaping happens during scoping, which is why this is build-to-order rather than an off-the-shelf AppSource download. We start with a short call to walk your houses, cycle structure, grades, feed programme and reporting needs, then send a written scope with the object list, fields, posting behaviour and reports. Once you confirm it, typical delivery is two to four weeks. We develop against your Business Central version — SaaS on the current release wave or on-premises — deploy to your sandbox first for user acceptance testing with real cycle data, then publish to production with a documented rollback. You receive the AL source, the git repository, technical and user documentation, a training session for farm and finance users, and a post-go-live support window while the first cycle runs through the system.