How to Download GitHub Invoices (2026 Guide)

If you use GitHub for anything past the free tier, you have probably noticed that the bill is never just one thing. A personal Copilot subscription is one charge. A Team plan with ten seats is another. If any of those seats push Actions minutes above the included allowance, that is a separate line item. Container registry storage, Packages bandwidth, LFS bandwidth, Advanced Security on Enterprise, Copilot Business on top of base seats. By the time you are running a meaningful development operation, your GitHub bill is a small stack of line items spread across (possibly) several organizations and one personal account.

And because personal billing and organization billing are completely separate, "get all my GitHub invoices" is usually shorthand for "get my personal invoices, plus invoices from the three orgs I am in, plus invoices from the two orgs I used to be in but still have billing access to." Four, five, six different billing pages to check every month. Each one with its own payment history, each one emailing its receipt to a potentially different address.

This guide covers the manual path for the most common case (personal + one organization), flags the multi-org complexity, and walks through pulling the whole lot into a single archive. We will be specific about which Settings page, which tab, and where the receipts actually live.

The manual way: downloading GitHub invoices

Personal and organization accounts follow the same pattern but live in completely separate UIs. We will walk through both.

Step 1: Personal account billing

Log in to GitHub at github.com. Click your profile photo in the top-right corner of any page and choose "Settings" from the dropdown. In Settings, look at the left sidebar and scroll down to the "Access" section. Click "Billing and plans," sometimes shown simply as "Billing."

The Billing page has tabs or sections for your current plan (Free, Pro, etc.), usage (Actions, Packages, Storage), payment information, and payment history. Click the "Payment information" tab (or scroll to it, depending on your UI version), and find the "Payment history" list near the bottom.

Each row is a past monthly charge. The columns are usually date, amount, and a "Receipt" link. Click "Receipt" on any row. GitHub opens a new tab with the receipt HTML page. To download as PDF, most browsers require you to use "Print to PDF" from the browser print dialog (File > Print > Save as PDF). There is no direct PDF download button. GitHub renders receipts as web pages, not as pre-generated PDFs, which is annoying when you want to archive them consistently.

Step 2: Organization billing

Organizations are where most real work happens, and their billing is completely separate from personal.

Click your profile photo to get to the account switcher. Choose the organization you want. Once you are viewing the organization page, click "Settings" at the top of the organization view. This is not the same Settings as your personal account; it is the organization's settings, which you can only access if you are an owner or a billing manager.

In the organization's settings, scroll the left sidebar to "Access" and click "Billing and plans." The layout is similar to personal billing: current plan, seat license count, usage, payment information, payment history. Under Payment history, each row has a Receipt link that opens in a new tab. Same Print-to-PDF dance to save it locally.

Important: only owners and users with the explicit "Billing manager" role can see these pages. If you are an organization member, even an admin, you usually cannot. For teams where the CEO owns the org but the CFO handles books, make sure the CFO has the Billing manager role or they will not be able to pull invoices at all.

Step 3: Repeat per organization

If you are in multiple organizations with different billing (one for the company, one for the open-source project you maintain, one for a contractor engagement), each one has its own billing page and its own payment history. There is no consolidated view across organizations. You switch contexts for every one.

For agencies or consultants who set up GitHub for clients, this is especially painful. Each client organization bills separately, and the receipts are usually sent to an email address the client controls, not yours. Either stay a billing manager on every client org forever, or set up a shared accounting inbox that is a billing contact on each.

Step 4: Rename and file

GitHub receipts, when you print to PDF, get a browser-default filename based on the page title. Usually something like github-com-receipt-{hash}.pdf or similar, depending on the browser. Rename to 2026-04_github_{org-name-or-personal}_{amount}.pdf before filing. The org name in the filename is mandatory if you manage multiple orgs.

Why manual breaks at scale

GitHub billing volume depends on how your company uses the platform. A single-developer indie account with Pro and Copilot is two lines on one monthly receipt. A 50-person engineering org with Enterprise, Copilot Business, and heavy Actions usage is a stack of line items on a bill that changes month to month as Actions spend fluctuates.

The pain points at scale show up in three places.

First, Actions variability. GitHub Actions is included up to a plan-specific allowance, then charged per minute beyond. For teams running heavy CI pipelines, this can add meaningful variable cost that differs every month. The receipt breaks it down, but only at the level of "Linux minutes," "Windows minutes," and "macOS minutes" (macOS is 10x pricier per minute). If you want to know which repository or workflow is consuming the minutes, you have to pull usage reports separately from the billing page's usage tab. Those reports are available for download as CSV, but they are not attached to the receipt. For engineering cost accountability, keeping both the receipt and the monthly usage CSV together is the only way to actually understand what you paid for.

Second, multi-org complexity. Real companies often end up with more organizations than they expected. One for production, one for open-source contributions, one for client work, one that someone set up five years ago and nobody remembers why. Each one bills separately, each one has its own seat count, each one might have its own payment method. Consolidating the books across all of them requires pulling from every org's billing page every month. Miss one, and you are underreporting expenses.

Third, PDF-less receipts. The HTML-receipt-then-print-to-PDF pattern means your archived receipts are browser screenshots, not original PDFs. This matters for compliance in some jurisdictions (France, Italy, and others have strict rules about what constitutes a valid invoice for tax purposes). A print-to-PDF receipt technically satisfies most audit requirements, but if your auditor wants to verify that the document was not modified, the chain of custody is weaker than with a vendor-generated PDF. Automated tools that process the receipt through a consistent pipeline and timestamp the capture produce better compliance artifacts than manual print-to-PDF.

For solo developers, the manual path is fine indefinitely. For engineering teams with two or more orgs and any Actions usage that varies month to month, the manual path starts consuming real time by the second org.

Manual vs automated

Automating with Inbox Ledger

GitHub emails a receipt summary to the billing contact of each account when a monthly charge succeeds. The email does not attach the PDF, but it is a reliable signal that a new invoice exists, and the pattern is consistent enough to process automatically.

Point billing emails at a processing inbox. For your personal account, your billing email is the same as your GitHub account email. For organization billing, in the organization's Settings > Billing and plans, under "Billing email," you can add or change the recipient address. Use a shared accounting inbox or an Inbox Ledger forwarding address. For multi-org operators, set the same email on every organization you own or manage billing for, so all the receipts land in one place.

Connect the inbox. Gmail, Outlook, or any IMAP via OAuth. Read-only mailbox access. The first sync pulls historical GitHub receipts from whatever window you pick. GitHub receipt emails have a consistent sender (support@github.com or billing@github.com depending on account type) and subject format, so extraction is reliable.

Handle the PDF fetch. Because GitHub does not attach the receipt PDF to the email, the extractor pulls the receipt data from the email body directly and generates a structured invoice record. For teams that need the actual PDF as an archive artifact, the Chrome extension can capture the receipt page on-demand and push it into the same archive, or you can pull the receipt HTML from GitHub's web UI programmatically if you have a session. Most teams find the structured data is sufficient for accounting; the PDF-as-archive requirement is more about compliance than workflow.

Split the line items. The extractor pulls every line on the receipt as its own structured field: seat licenses, Actions minutes by OS type, Packages bandwidth, LFS bandwidth, Copilot seats, Advanced Security if applicable. This matters for accounting because different lines often belong in different GL accounts. Seat licenses are software subscriptions, Actions is CI infrastructure, Packages is artifact storage. Routing rules can split one GitHub invoice into three entries in QuickBooks or Xero automatically.

Route to accounting. Rules push extracted data to QuickBooks, Xero, Google Sheets, Google Drive, or OneDrive. A common rule set for engineering-heavy companies: seat licenses to "Software Subscriptions," Actions and Packages to "CI/CD Infrastructure," Copilot to "Developer Tools," each tagged by the organization name for per-team cost allocation.

For GitHub-specific walkthroughs, including how to configure per-org billing emails, how to handle the Billing manager role assignment, and how to process Enterprise contract invoices (which come separately from monthly receipts for annual prepay), see our GitHub billing portal page.

The integrations page lists every accounting destination, including QuickBooks and Xero with per-line-item routing for teams that split engineering tool costs across multiple GL accounts. AI processing covers how the extractor separates GitHub's line items, especially the Actions minutes by OS which affect unit economics for teams running heavy Mac-specific CI. If your team works inside GitHub daily, the Chrome extension adds a one-click send button on receipt pages, useful for capturing the full HTML receipt alongside the extracted data. For teams specifically allocating CI costs across engineering projects, the AI invoice extractor tool walks through the line-item parsing in detail.

Gotchas and edge cases

A few things that trip up engineering leaders and their finance counterparts.

Plan seat count vs active user count. GitHub charges for seat licenses based on the seat count you have configured, not the actual active users. If you set the seat count at 20 but only 12 people are using the org, you are paying for 20 seats. Mid-cycle, if you drop the seat count to 12, GitHub prorates a credit on the next bill. If you increase it to 25, you are charged the prorated difference immediately. The receipt shows the final count and amount, but not the mid-cycle changes. For a team that resizes frequently, the billing page's Usage tab has the seat activity history, but the receipt alone does not. Automated extraction captures the receipt-visible data; for seat history, you still need the Usage tab.

Copilot Business seats are separate from org seats. Adding Copilot Business to an organization is a separate line item, priced per user assigned. It is not automatic: you have to explicitly assign Copilot to each team member, and each assignment adds to the next invoice. A frequent surprise is "we added 10 new hires, did Copilot get assigned, why did the bill jump by $190?" Trace Copilot Business assignments through the org's Copilot settings, not through the billing page. The billing line item tells you the total seats but not who is using them.

Marketplace purchases. GitHub Marketplace apps (Codecov, Sentry, Travis CI alternatives, etc.) billed through GitHub show up on your org invoices as separate line items. Some apps bill directly via their own systems, similar to Shopify. For a full picture of engineering tooling spend, you need both: GitHub-billed Marketplace charges (captured automatically on org invoices) and directly-billed SaaS from the same vendors (captured separately from their own billing systems).

Trial expirations mid-cycle. When a GitHub Advanced Security trial ends, the next invoice includes a prorated charge for the portion of the cycle after the trial conversion. If you did not realize Advanced Security had auto-enabled billing, the bill suddenly has a new line item. Watch for "first appeared" line items on invoices and treat them as signals to check whether a new feature or trial conversion was enabled that you did not intend.

Refunds and disputes. GitHub refunds appear as negative entries on the next invoice with a note about the reason (seat reduction, trial cancellation, support adjustment). Manual archivers often miss these because the amount column shows a positive total and the negative line is small. For accurate expense tracking, negative line items have to net against the original charge, ideally in the same period. Automated extraction tags these as "credit" or "adjustment" and keeps them linked to the original transaction.

When automation is not worth it

Solo developer with one personal account, Copilot subscription, maybe Pro. Your monthly GitHub receipt is one email, one line, one minute of work to file. Do not automate that. Drop the receipt email into a "GitHub" folder in your mail client and move on.

Automation earns its keep at three inflection points. First, when you have two or more organizations (the manual effort roughly doubles per org and the miss rate climbs). Second, when you have heavy Actions usage with variable monthly spend that needs line-item cost attribution. Third, when GitHub is part of an engineering tooling budget that also includes half a dozen other SaaS vendors that all need processing in a unified workflow.

Also worth noting: if your engineering team runs on a platform that already processes SaaS invoices (a spend management tool, an AP automation system), check that it handles GitHub line-item extraction well before adding a separate tool. GitHub's line-item complexity is where some generic tools fall short, and the right answer depends on what your stack already does.

Closing: line items matter more than totals

GitHub billing is a good example of a vendor where the total on the invoice tells you very little. The interesting information is in the line items: which organizations, which OS minutes for Actions, how many Copilot seats, how much storage. That is the data engineering leaders actually want, and that is what gets lost when the finance team just drops the PDF in a folder called "GitHub 2026."

Manual download produces a pile of receipts with surface-level totals. Automated extraction produces structured line-item data you can query, attribute, and forecast against. For solo developers and small teams, the manual path is fine. For engineering organizations where tooling cost is a real line in the budget, the line-item data is worth having in an accounting system instead of a stack of PDFs.

If you want to see what Inbox Ledger does with GitHub receipts and how the line items land in accounting, start with the integrations page, connect a mailbox, and wait for next month's receipt. The line-item breakdown will land in your accounting system automatically, ready to route to the right GL account.