SUMA.WARUNKÓW w Excelu: produkt, region i miesiąc

Chcesz policzyć sprzedaż jednego produktu, w jednym regionie i w konkretnym miesiącu. Możesz filtrować tabelę ręcznie, kopiować wiersze i za każdym razem zastanawiać się, czy coś zostało ukryte. Ja wolę zapisać te warunki w formule. Wtedy widzę, co właściwie policzyłem, a zmiana miesiąca nie oznacza ponownego składania raportu.

Do tego służy SUMA.WARUNKÓW, czyli angielskie SUMIFS. W polskiej nazwie jest kropka. W tym poradniku przejdę przez jeden mały zbiór syntetyczny, od prostego wyboru produktu do raportu miesięcznego. Najwięcej uwagi poświęcę miejscom, w których poprawnie wpisana formuła potrafi odpowiedzieć na niewłaściwe pytanie.

Jakie warunki łączy SUMA.WARUNKÓW

Funkcja dodaje kwoty z wierszy spełniających wszystkie podane kryteria. Produkt, region i data dotyczą tego samego wiersza. Nie wystarczy, że produkt znajdzie się gdzieś w tabeli, a region w zupełnie innym miejscu.

Według dokumentacji Microsoft najpierw podaję zakres sumowania, a następnie pary: zakres sprawdzany i kryterium. Mogę zacząć od jednego warunku i dopisywać kolejne. Podstawowa konstrukcja wygląda tak:

=SUMA.WARUNKÓW(zakres_sumy;zakres_kryterium1;kryterium1;zakres_kryterium2;kryterium2)

Polskie przykłady używają nazw PL i średników. W angielskim Excelu zobaczysz SUMIFS oraz zwykle przecinki. Separator argumentów zależy od konfiguracji regionalnej. Podpowiedź w Twoim Excelu jest dobrym sposobem sprawdzenia, jakiej pisowni oczekuje program.

Funkcja zwraca sumę, a nie listę transakcji. Jeżeli potrzebujesz wskazać konkretne zamówienia, wynik liczbowy będzie za mało szczegółowy. Jeśli chcesz policzyć ich liczbę, potrzebujesz funkcji zliczającej. To brzmi banalnie, ale łatwo pomylić sprzedaż z liczbą sprzedanych pozycji, gdy obie kolumny zawierają liczby.

Sześć wierszy do wspólnego przykładu

Wklej nagłówki do A1:E1, a dane do wierszy 2:7. Wszystkie liczby i transakcje są syntetyczne. Kolumna C zawiera prawdziwe daty Excela, nie tekst wyglądający jak data. Kolumna E zawiera kwoty liczbowe, bez dopisanej w komórce waluty.

Przed liczeniem ustalam, co znaczy jeden wiersz: jedna transakcja o danym statusie. Jeśli dane pochodzą z eksportu pozycji zamówienia, jedno zamówienie może mieć kilka wierszy. Sumowanie kwot pozycji będzie wtedy sensowne, lecz sumowanie powtórzonej wartości całego zamówienia już nie. Funkcja nie zna modelu Twojego eksportu.

Daty możesz zbudować przez DATA, np. =DATA(2026;10;1). Tak unikasz zgadywania, czy zapis 01/10 oznacza styczeń, czy październik. Microsoft wyjaśnia składanie dat z roku, miesiąca i dnia w opisie funkcji DATA.

Najpierw produkt, potem region

Zaczynam od całej kawy:

=SUMA.WARUNKÓW($E$2:$E$7;$A$2:$A$7;"Kawa")

Do sumy wchodzą wiersze 2, 3, 5, 6 i 7. Wynik to 370. To nadal obejmuje listopad i anulowaną transakcję. Na tym etapie nie mam powodu oczekiwać sprzedaży październikowej.

Dokładam region:

=SUMA.WARUNKÓW($E$2:$E$7;$A$2:$A$7;"Kawa";$B$2:$B$7;"Północ")

Teraz zostają wiersze 2, 3, 6 i 7, czyli 250. Transakcja z Południa odpada. Lubię budować formułę w ten sposób, ponieważ po każdym kroku potrafię wskazać wiersze, które przestały pasować. Przy dużej tabeli tę samą kontrolę robię na małej próbce.

Miesiąc zapisuję jako dwie granice

Załóżmy, że chcę kawę z Północy w październiku, wyłącznie ze statusem Gotowe. W H2 wpisuję Kawa, w H3 Północ, w H4 datę =DATA(2026;10;1), w H5 =DATA(2026;11;1), a w H6 Gotowe.

=SUMA.WARUNKÓW($E$2:$E$7;$A$2:$A$7;$H$2;$B$2:$B$7;$H$3;$C$2:$C$7;">="&$H$4;$C$2:$C$7;"<"&$H$5;$D$2:$D$7;$H$6)

Dwa warunki dotyczą tej samej kolumny dat: co najmniej początek października i mniej niż początek listopada. Znak & łączy operator porównania z wartością komórki. Sam napis ">=H4" nie odwołuje się poprawnie do daty z H4; litery zostałyby częścią kryterium tekstowego.

Wiersze 2 i 3 spełniają wszystkie warunki, dając 150. Wiersz 4 odpada przez produkt, 5 przez region, 6 przez miesiąc, a 7 przez status. Takie wyjaśnienie wyniku jest dla mnie znacznie cenniejsze niż informacja, że Excel wyświetlił jakąś liczbę bez błędu.

Górna granica wyłączna przydaje się także wtedy, gdy dane mają godzinę. Transakcja z 31 października o 18:00 nadal jest wcześniejsza niż 1 listopada o północy. Warunek „mniejsze lub równe 31 października” wskazujący północ mógłby zgubić późniejsze godziny tego dnia. W raporcie ustalam też, w jakiej strefie czasowej zapisano daty źródłowe.

Nie filtruję wyłącznie numeru miesiąca. Październik 2025 i październik 2026 mają ten sam numer. Granice dat obejmują konkretny okres, dzięki czemu kolejne lata nie wpadają do tej samej sumy przez przypadek.

Dlaczego zakresy muszą do siebie pasować

Każdy zakres w przykładzie zaczyna się od wiersza 2 i kończy na 7. Excel porównuje odpowiadające sobie pozycje zakresów. Kryterium z pierwszej pozycji ma decydować o kwocie z pierwszej pozycji, a nie o kwocie z sąsiedniej transakcji.

Różne rozmiary zakresów są opisane jako przyczyna błędu w pomocy Microsoft dla SUMA.WARUNKÓW. Równie groźne bywa przesunięcie zakresów tej samej długości. Formuła może wtedy wyglądać poprawnie, lecz sprawdzać produkt z innego wiersza niż kwotę.

Dlatego nie naprawiam błędów przez losowe rozszerzanie zaznaczeń. Najpierw sprawdzam początek, koniec i znaczenie każdej kolumny. W pliku dostarczonym przez inną osobę kontroluję też, czy między danymi nie znajdują się subtotalne wiersze. Suma szczegółów razem z ich podsumowaniami da zawyżony wynik.

Znaki $ blokują odwołania podczas kopiowania formuły. W tym przykładzie także komórki kryteriów pozostają stałe. Jeśli budujesz tabelę raportową, możesz świadomie pozostawić część odwołania względną. Mechanizm opisuje dokumentacja odwołań.

ORAZ w jednej formule, LUB między wariantami

Dwa warunki Produkt = Kawa i Produkt = Herbata wpisane jako kolejne kryteria jednej formuły wymagają, żeby ta sama komórka miała obie wartości jednocześnie. W zwykłej tabeli produktów taki wiersz nie wystąpi. Nie uzyskasz w ten sposób sumy kawy lub herbaty.

Dla dwóch rozłącznych nazw mogę dodać dwie sumy:

=SUMA.WARUNKÓW($E$2:$E$7;$A$2:$A$7;"Kawa")+SUMA.WARUNKÓW($E$2:$E$7;$A$2:$A$7;"Herbata")

Wynik wynosi 450. Każdy wiersz ma jedną nazwę produktu, więc grupy się nie pokrywają. Ten sposób przestaje być bezpieczny, gdy warunki to na przykład „Kawa” lub „Północ”. Część transakcji spełnia oba i zostałaby policzona dwa razy.

Przy nakładających się warunkach dodaję kolumnę pomocniczą z jedną decyzją dla każdego wiersza albo zmieniam sposób agregacji. Przed sumowaniem chcę wiedzieć, czy wybrane grupy są rozłączne. Sam znak plus nie rozwiązuje problemu podwójnego liczenia.

Zera, tekst i inne sygnały ostrzegawcze

Wynik zero nie mówi, czy nie było sprzedaży, czy żaden rekord nie pasował. Warto pokazać obok liczbę dopasowanych transakcji, szczególnie w raporcie używanym przez innych. Inaczej brak danych bardzo łatwo zmienia się w rzekomo dobry lub zły wynik biznesowy.

Gdy spodziewam się kwoty, a dostaję zero, sprawdzam po kolei nazwę produktu, region, daty i status. Usuwam chwilowo ostatni warunek i patrzę, czy istnieje choć jeden pasujący wiersz. Nie zmieniam wszystkich kryteriów naraz, bo wtedy nie dowiem się, które było przyczyną problemu.

Kwoty zapisane jako tekst wymagają osobnego uporządkowania. Samo ustawienie formatu walutowego nie jest planem konwersji importu. Microsoft opisuje konwersję liczb przechowywanych jako tekst. Najpierw potwierdzam separator dziesiętny i znaczenie jednostki. Sto złotych i sto groszy to równie poprawne liczby, ale zupełnie inne kwoty.

Przy nazwach sprawdzam także odstępy. Kawa i tekst z niewidoczną spacją na końcu mogą prowadzić do trudnych do zauważenia rozbieżności. Wolę uporządkować kolumnę pomocniczą niż dopisywać coraz szersze kryterium z nadzieją, że obejmie brudne dane.

Gwiazdka zmienia znaczenie dopasowania

Kryterium "Kaw*" może wybrać wiele nazw zaczynających się od tego fragmentu. * dopasowuje ciąg znaków, a ? pojedynczy znak. Zapis ~* służy do szukania dosłownej gwiazdki. To wygodne przy rodzinie produktów, lecz ryzykowne przy identyfikatorach, w których gwiazdka jest prawdziwym znakiem.

W raporcie pokazuję pełne kryterium obok wyniku. Odbiorca powinien wiedzieć, czy liczba dotyczy jednej nazwy, czy szerokiej grupy. Zmiana Kawa na Kaw* może zwiększyć sumę bez dodania choćby jednej nowej transakcji do źródła.

Rosnący raport i dane z kilku arkuszy

Stały zakres E2:E7 dobrze nadaje się do nauki. W regularnym raporcie nowe rekordy mogą pojawić się pod jego końcem. Formuła pozostanie poprawna, ale pominie nową sprzedaż. To jeden z tych błędów, które nie mają uprzejmości pokazać czerwonego komunikatu.

Po zamianie danych w tabelę Excela o nazwie Sales i kolumnach Amount, Product, Region mogę użyć odwołań strukturalnych:

=SUMA.WARUNKÓW(Sales[Amount];Sales[Product];$H$2;Sales[Region];$H$3)

Odwołania tabeli dostosowują się do jej danych; zasady opisuje Microsoft. Nadal sprawdzam, czy nowy wiersz rzeczywiście stał się częścią tabeli. Sam kolor w sąsiedniej komórce tego nie dowodzi.

Jeżeli każdy miesiąc leży w osobnym arkuszu, jedna zwykła formuła SUMA.WARUNKÓW nie scala automatycznie ich układu. Dla kilku zgodnych arkuszy można dodać oddzielne sumy. Przy regularnym dopływie plików wolę najpierw przygotować jedną tabelę, np. przez Power Query, i dopiero na niej budować raport.

Jak przekazać raport komuś innemu

W gotowym pliku obok wyniku zapisuję nazwę miary i okres. „Sprzedaż” to czasem kwota brutto, czasem netto, a czasem suma zamówień jeszcze przed anulowaniem. Nasz przykład liczy kwoty ze statusem Gotowe. Osoba otwierająca plik za miesiąc powinna odczytać to z nagłówka, zamiast odtwarzać sens raportu z siedmiu argumentów formuły.

Podobnie traktuję ujemne kwoty. Jeżeli w źródle są zwroty, warto ustalić, czy mają pomniejszać sprzedaż, czy trafić do osobnego zestawienia. W naszym małym zbiorze wszystkie kwoty są dodatnie. W rzeczywistym eksporcie dodatnia transakcja 100 i zwrot -100 dadzą zero, mimo że wydarzyły się dwa zdarzenia. Suma jest wtedy poprawna rachunkowo, ale potrzebuje objaśnienia.

Nie usuwam zwrotu tylko po to, żeby raport wyglądał przyjemniej. Najpierw ustalam definicję miary, potem dobieram kryteria. Gdy raport ma pokazywać wartość sprzedaży przed zwrotami, zapisuję to w nazwie. Gdy ma pokazywać saldo, pozostawiam odpowiednie znaki. Ten sam mechanizm sumowania obsłuży obie definicje.

Osobno liczba i opis wyniku

Kwotę pozostawiam w komórce liczbowej. Opis „Kawa, Północ, październik” umieszczam obok. Dzięki temu inne obliczenia mogą korzystać z sumy, a format walutowy odpowiada tylko za prezentację. Dopisywanie słowa „zł” przez łączenie tekstu z wynikiem utrudnia dalszą pracę z takim polem.

Kryteria w H2:H6 traktuję jako część raportu. Nie chowam ich daleko na końcu arkusza, gdzie nikt nie zauważy zmiany regionu. Przy pliku przekazywanym dalej dopisuję krótki opis, które pola służą do wyboru okresu, a które są danymi źródłowymi. To znacznie tańsze niż późniejsze wyjaśnianie dwóch różnych wersji tej samej liczby.

Jeżeli odbiorca ma porównywać kilka miesięcy, sprawdzam też porównywalność. Październik z pełnym importem i listopad z jednym dniem danych nie tworzą uczciwego porównania dynamiki. Formuła wykona oba obliczenia, więc odpowiedzialność za opis okresów zostaje przy autorze raportu.

SUMA.JEŻELI i SUMA.WARUNKÓW mają inną kolejność

Przy jednym kryterium można spotkać obie funkcje. Dla naszego produktu odpowiednik pierwszego przykładu to:

=SUMA.JEŻELI($A$2:$A$7;"Kawa";$E$2:$E$7)

Tu zakres sumowania jest na końcu. W SUMA.WARUNKÓW zaczyna listę argumentów. Nie wystarczy dopisać końcówki do nazwy funkcji i kolejnej pary warunków. Po takiej edycji trzeba świadomie ułożyć argumenty od nowa. Microsoft wskazuje tę różnicę w dokumentacji obu zastosowań.

Ja przy planowanym rozbudowywaniu raportu często zaczynam od SUMA.WARUNKÓW, nawet gdy pierwsza wersja ma tylko produkt. Dodanie regionu jest wtedy dopisaniem nowej pary. To preferencja organizacyjna, bez obietnicy szybszego liczenia. Wybieram układ, który będzie łatwiejszy do przeczytania podczas kolejnej zmiany.

Kiedy wybrać tabelę przestawną

Jedna formuła jest wygodna przy pojedynczym wskaźniku albo małym zestawie wyników. Jeżeli potrzebujesz pełnego przekroju wszystkich produktów i regionów, ręczne budowanie wielu podobnych formuł może stać się uciążliwe. Tabela przestawna pozwala wygodniej eksplorować taki układ. Wybór narzędzia zależy od tego, czy projektujesz stały panel, czy szukasz zależności w danych.

Przy każdym z tych rozwiązań wracam do tego samego pytania: które wiersze weszły do liczby? W razie rozbieżności między raportami porównuję populacje i definicje, zanim zacznę zmieniać funkcje. Najczęściej dopiero wtedy widać, że jedna osoba wlicza anulowane zamówienia albo bierze datę wysyłki zamiast daty zakupu. Formuła nie rozstrzygnie tego za zespół.

Przy sprawdzaniu zakresu źródła zwracam uwagę także na kompletność pliku. Poprawny filtr października nie pomoże, jeżeli eksport urwał się po piętnastym dniu miesiąca. Wtedy ładnie opisany wynik nadal dotyczy tylko fragmentu okresu. Zanim wyślę raport, porównuję datę ostatniego rekordu z oczekiwanym zakresem dostawy i potwierdzam, że import rzeczywiście się zakończył. To osobna kontrola względem poprawności samej formuły.

Małe ćwiczenie przed własnym raportem

Na danych z tabeli policz całą kawę z Północy, potem ogranicz ją do października, a na końcu wyklucz anulowane transakcje. Oczekiwane wyniki to kolejno 250, 180 i 150. Różnica między drugim a trzecim wynikiem pochodzi dokładnie z jednego wiersza o kwocie 30.

Następnie przesuń datę transakcji z wiersza 6 na 31 października. Końcowa suma powinna wzrosnąć do 220. Zanim poprawisz formułę po zmianie danych, spróbuj sam wskazać, dlaczego dany wiersz ma wejść do wyniku. To ćwiczenie sprawdza rozumienie warunków, a nie pamięć do kolejności argumentów.

Gdy chcesz przejść dalej, zobacz JEŻELI i łączenie warunków przez ORAZ oraz LUB. Własny raport zacznij od zapisania jednego zdania: co liczę, z których wierszy i za jaki okres. Dopiero potem wpisuj znak równości.

Wersja do oglądania