A build-to-order Dynamics 365 Business Central extension that tracks vendor 1099 amounts throughout the year — W-9 and TIN capture, box mapping applied at posting, threshold and correction handling — and produces validated, e-file-ready output plus recipient copies. Built, installed and supported by ECOSIRE for your Business Central version. Built to order by ECOSIRE for Dynamics 365 BC (build-to-order) — indicative price from $499.00 USD; request a quote for a scoped proposal.
Illustrative previewA build-to-order Dynamics 365 Business Central extension that tracks vendor 1099 amounts throughout the year
— W-9 and TIN capture, box mapping applied at posting, threshold and correction handling — and produces validated, e-file-ready output plus recipient copies. Built, installed and supported by
ECOSIRE for your Business Central version.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.
You go live in about 2–4 weeks, with a post-launch support window.
Every January the same scramble starts. Accounts payable exports a year of vendor payments to Excel, someone hand-filters the contractors from the incorporated suppliers, TINs get chased by email in the last week, and the totals never quite tie back to the vendor ledger. Business Central does ship the basics — IRS 1099 Form-Box codes on the vendor card and on purchase invoice lines, a vendor 1099 report, and printable forms — but the native flow assumes the box code was set correctly on every document at posting time, offers no structured W-9 or TIN-type record, treats amounts as invoice-based rather than payment-application-based, and gives you nothing usable when a recipient calls in March to say their figure is wrong. Corrections happen outside the system, which means next year's audit trail has a hole in it.\n\nThe USA 1099 & E-File Pack is an AL extension we build for your Business Central tenant that closes those gaps end to end. On the vendor side, a table extension and page extension add W-9 received date, TIN, TIN type (EIN or SSN), backup-withholding status and solicitation history to the vendor card, with a validation codeunit that flags incomplete or duplicate TINs before season instead of during it. On the transaction side, event subscribers on posting capture 1099-eligible amounts into a dedicated ledger keyed to vendor, box code, payment date and applied entry — so the figure you report follows the money, not the invoice. Box assignment is driven by configurable rules (by vendor, purchase account, dimension value or item category) with a per-line override that is still visible after posting, which is what makes reruns and audits sane.\n\nThe year-end run itself is a codeunit that builds a validated staging table: per-box thresholds applied, below-threshold vendors suppressed with the reason recorded, missing TINs and address problems listed as exceptions you can clear before anything leaves the system. From that staging table the extension produces both an IRS fixed-width e-file layout and a CSV shaped for your filing service, plus recipient copies. A corrected-return run reads the prior filed snapshot and emits only the deltas, keeping a permanent record of what was transmitted and when. Optional API pages (REST API v2.0 / OData v4) expose the staging data if you want it in Power BI or a Power Automate flow, and long-running builds can be scheduled through a job queue entry rather than tying up a user session.\n\nBecause this is an extension and not a modification, it stays upgrade-safe: table extensions, page extensions, codeunits and event subscribers only, no base-application changes, with dedicated permission sets so AP clerks, the controller and the auditor each see the right slice. We build it against your current Business Central release wave and target either SaaS (per-tenant extension) or on-premises deployment, whichever you run.\n\nThis is a build-to-order product, not an AppSource download. After you request a quotation we run a scoping call — your Business Central version and deployment model, your chart of accounts and how contractor spend actually posts, which boxes you file (1099-NEC and 1099-MISC are the usual pair), your filing service or transmitter, and how vendor onboarding captures W-9s today. From confirmed scope, typical delivery is two to four weeks: development, then UAT on a sandbox copy of your production database against an agreed acceptance script, then a production install with a documented rollback. You receive the full AL source in your own Git repository, so the extension is yours to keep, extend or hand to another partner.
Signs off the filing and carries the risk if a recipient figure is wrong or a TIN is missing. Wants amounts that reconcile to the vendor ledger without a spreadsheet in between, a documented reason for every suppressed vendor, and a correction path that leaves an audit trail instead of an email chain.
Owns vendor onboarding and the January scramble. Needs W-9 and TIN status visible on the vendor card, a pre-season list of vendors with 1099 activity but incomplete paperwork, and box assignment that happens at posting so recurring bills stop being classified by memory.
Responsible for keeping the tenant upgrade-safe across release waves. Wants extension-only architecture with no base-app modification, a defined object ID range, documented event subscribers and permission sets, and the AL source in a Git repository they control.
Files across several legal entities and currently repeats the same manual process in each one. Needs a consistent configuration per company, API-accessible staging data for Power BI oversight, and a fixed-scope engagement with a known delivery date ahead of the season.
| Criterion | ECOSIRE | Custom Build | Competitor | Dynamics 365 Business Central Native |
|---|---|---|---|---|
| 1099 amount tracking | Purpose-built ledger entries capture 1099-eligible amounts at payment application, per vendor and per box code | Whatever your AL developer scopes; usually starts as a report over G/L and grows fragile | Generic tracking that may assume a US-only chart of accounts and posting flow | IRS 1099 Form Box codes exist on vendor and purchase invoice lines, but reporting is thin and correction handling is manual |
| W-9 and TIN control | W-9 status, TIN, TIN type and solicitation dates tracked on the vendor card with pre-season completeness checks | Custom table extension you specify and maintain yourself | Often present, but field set and validation rarely match your onboarding process | No structured W-9 or TIN-type tracking; teams use free-text fields and spreadsheets |
| Box mapping accuracy | Rules by vendor, purchase account, dimension or item category, applied at posting via event subscribers with an override on the document line | Hand-coded rules that drift as your chart of accounts changes | Fixed mapping model; edge cases handled outside the app | Manual per-line box selection, easily forgotten on recurring bills |
| E-file output | IRS-layout fixed-width file plus CSV for your filing service, generated to a validated staging table you can review first | You own the file layout research and every annual format change | Export exists, but the target service is chosen by the vendor, not by you | Printed forms and basic export; no validated e-file staging workflow |
| Corrections and thresholds | Per-box thresholds, below-threshold suppression, and corrected-return runs that keep an audit trail of what was filed when | Usually deferred to phase two and never built | Varies widely; corrections are the most common gap | No correction run concept; you re-file outside Business Central |
| Fit to your setup | Scoped to your chart of accounts, vendor onboarding and filing service before a line of AL is written | Fully bespoke, but you carry the analysis and rework cost | You adapt your process to the app's assumptions | You adapt entirely, plus spreadsheets |
| Upgrade and release-wave safety | Table and page extensions plus event subscribers only, no base-app modification; validated against current release waves before each handover | Depends on the developer's discipline; base-app copies are common in rushed builds | Vendor controls the upgrade cadence and may lag a wave | Microsoft handles upgrades, but you inherit the functional gaps |
| Ownership and source code | Full AL source in your own Git repository, yours to extend or hand to another partner | You own it, along with the whole maintenance burden | Compiled app; no source, and per-tenant licence renewals | Not applicable |
This is build-to-order, so nothing is downloadable today. Typical delivery is two to four weeks from confirmed scope. It starts with a scoping call of about 30 minutes covering your Business Central version and deployment model, how contractor spend posts today, which 1099 forms and boxes you file, and which filing service or transmitter you use. We then send a fixed scope and quotation. Once you confirm, development begins, followed by UAT on a sandbox copy of your production database and a scheduled production install. If you are approaching a filing deadline, tell us at the scoping call — sequencing the work is a scope question and we would rather set an honest date than a hopeful one.
It does not transmit to the IRS itself. Becoming a transmitter is a separate regulatory undertaking with its own IRS registration. What the extension produces is validated, e-file-ready output: an IRS fixed-width layout file plus a CSV shaped for your filing service, and recipient copies. Most clients keep an existing transmitter and simply stop hand-building the file. We confirm your specific service's expected format during scoping and target it precisely.
Every build includes a post-go-live support window with a named engineer for defect fixes and configuration questions; the length is set in the quotation. Because the extension uses only table extensions, page extensions, codeunits and event subscribers with no base-application modification, Microsoft's monthly service updates and release waves do not normally break it. Where a wave changes something we depend on, we tell you before the update reaches your production environment. Annual IRS layout or threshold changes are handled as a small scoped update rather than a rebuild, since the box codes, thresholds and file layout are configuration, not hard-coded logic. You also hold the full AL source in your own Git repository, so you are never dependent on us to make a change.
Native box codes are a good starting point and the extension uses them. The gaps they leave are the ones that cost time: they only apply if someone set the code correctly on every line at posting, they are invoice-oriented rather than payment-application-oriented, there is no structured W-9 or TIN-type record, no threshold suppression with a recorded reason, and no correction-run concept at all. If your season is currently a spreadsheet plus a week of reconciliation, that gap is what we are closing.
Both, within reason. The extension reads existing vendor ledger entries and applied payment entries, so prior-year amounts can be rebuilt rather than typed in. During scoping we look at how clean that history actually is — misposted accounts, vendors that changed from individual to incorporated mid-year, and payments applied across years are the usual complications. Historical data preparation is included as a deliverable, and if the history needs substantial cleanup we say so and price it explicitly instead of discovering it during UAT.
Yes. The same AL codebase targets both. On SaaS it deploys as a per-tenant extension through your admin centre; on-premises it deploys as a signed .app to your service tier. We build and test against the release wave you are actually running, and the version is fixed in writing in the scope document so there is no ambiguity at install time.
You get the full AL source in your own Git repository, along with the build configuration and the release .app artefacts. There is no per-tenant licence renewal and no vendor lock. If you later want your internal team or a different partner to extend it, everything they need is already in your hands.

Configurable, rule-based approval matrices for every Business Central document type, with per-workflow approvers, amount limits, delegation, and email/mobile responses. Built and installed by ECOSIRE as a per-tenant AL extension.

A build-to-order AL extension that brings Adyen's 150+ global payment methods and unified settlement reconciliation into Business Central accounts receivable, complementing the first-party D365 Commerce Adyen connector.

A build-to-order Business Central extension that registers affiliates and referrers, attributes sales to referral codes and links, calculates tiered commission, and posts payouts as vendor invoices — installed per-tenant and supported by ECOSIRE.

A build-to-order AL extension that adds localized, multi-country African payroll to your Business Central tenant — per-country PAYE and statutory deductions, multi-currency multi-entity runs, statutory filing exports, and employee self-service payslips.
A build-to-order Dynamics 365 Business Central extension that tracks vendor 1099 amounts throughout the year — W-9 and TIN capture, box mapping applied at posting, threshold and correction handling — and produces validated, e-file-ready output plus recipient copies. Built, installed and supported by ECOSIRE for your Business Central version.